RE: [PATCH drm/amdgpu/psp: ignore psp reponse status] drm/amdgpu/psp: ignore psp reponse status

2019-01-14 Thread Yu, Xiangliang
Please add more comments to explain why don't return error.
And add my RB with that fix.

Reviewed-by: Xiangliang Yu

-Original Message-
From: amd-gfx  On Behalf Of Aaron Liu
Sent: Monday, January 14, 2019 4:17 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Aaron 
Subject: [PATCH drm/amdgpu/psp: ignore psp reponse status] drm/amdgpu/psp: 
ignore psp reponse status

Don't return err if psp reponse status isn't zero

Change-Id: I680679983f972b6969f4949f1faafaf17fe996a6
Signed-off-by: Aaron Liu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 53c2d60..48778b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -140,14 +140,15 @@ psp_cmd_submit_buf(struct psp_context *psp,
while (*((unsigned int *)psp->fence_buf) != index)
msleep(1);
 
-   /* the status field must be 0 after psp command completion */
+   /* the status field should be 0 after psp command completion
+* if not, print WARN msg
+*/
if (psp->cmd_buf_mem->resp.status) {
if (ucode)
-   DRM_ERROR("failed to load ucode id (%d) ",
+   DRM_WARN("failed to load ucode id (%d) ",
  ucode->ucode_id);
-   DRM_ERROR("psp command failed and response status is (%d)\n",
+   DRM_WARN("psp command failed and response status is (%d)\n",
  psp->cmd_buf_mem->resp.status);
-   return -EINVAL;
}
 
/* get xGMI session id from response buffer */
-- 
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 2/2] drm/amdgpu/psp: Fix can't detect psp INVOKE command failed

2019-01-03 Thread Yu, Xiangliang
XGMI command will not load ucode, so it can't find the command failed if check 
ucode at first.
For code logic, should check response status to see if command complete 
successfully at first.
For Vega10, could you explain why it block older version fw?


-Original Message-
From: Christian König  
Sent: Thursday, January 03, 2019 11:00 PM
To: Xu, Feifei ; Yu, Xiangliang ; 
amd-gfx@lists.freedesktop.org; Deucher, Alexander 
Subject: Re: [PATCH 2/2] drm/amdgpu/psp: Fix can't detect psp INVOKE command 
failed

Hi guys,

this patch broke loading older versions of PSP firmware on Vega10.

What exactly is the background here? E.g. why do we need it? And can we revert 
it ASAP?

Thanks,
Christian.

Am 18.12.18 um 03:45 schrieb Xu, Feifei:
> Reviewed-by: Feifei Xu 
>
> -Original Message-
> From: amd-gfx  On Behalf Of 
> Xiangliang Yu
> Sent: Thursday, December 13, 2018 3:42 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang 
> Subject: [PATCH 2/2] drm/amdgpu/psp: Fix can't detect psp INVOKE 
> command failed
>
> There isn't ucode when executing INVOKE command, so current code can't check 
> the failure of INVOKE command.
>
> Remove the ucode check.
>
> Signed-off-by: Xiangliang Yu 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 11 +++
>   1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index 2f126ea7..7f5ce37 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -140,10 +140,13 @@ psp_cmd_submit_buf(struct psp_context *psp,
>   while (*((unsigned int *)psp->fence_buf) != index)
>   msleep(1);
>   
> - /* the status field must be 0 after FW is loaded */
> - if (ucode && psp->cmd_buf_mem->resp.status) {
> - DRM_ERROR("failed loading with status (%d) and ucode id (%d)\n",
> -   psp->cmd_buf_mem->resp.status, ucode->ucode_id);
> + /* the status field must be 0 after psp command completion */
> + if (psp->cmd_buf_mem->resp.status) {
> + if (ucode)
> + DRM_ERROR("failed to load ucode id (%d) ",
> +   ucode->ucode_id);
> + DRM_ERROR("psp command failed and response status is (%d)\n",
> +   psp->cmd_buf_mem->resp.status);
>   return -EINVAL;
>   }
>   
> --
> 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

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


RE: [PATCH] drm/amdgpu: psp_ring_destroy cause psp->km_ring.ring_mem NULL

2018-12-17 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu 



-Original Message-
From: Lou, Wentao  
Sent: Tuesday, December 18, 2018 3:52 PM
To: amd-gfx@lists.freedesktop.org
Cc: Lou, Wentao 
Subject: [PATCH] drm/amdgpu: psp_ring_destroy cause psp->km_ring.ring_mem NULL

psp_ring_destroy inside psp_load_fw cause psp->km_ring.ring_mem NULL.
Call Trace occurred when psp_cmd_submit.
should be psp_ring_stop instead.

Change-Id: Ib332004b3b9edc9e002adc532b2d45cdad929b05
Signed-off-by: Wentao Lou 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 7f5ce37..8189a90 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -547,7 +547,7 @@ static int psp_load_fw(struct amdgpu_device *adev)
struct psp_context *psp = >psp;
 
if (amdgpu_sriov_vf(adev) && adev->in_gpu_reset) {
-   psp_ring_destroy(psp, PSP_RING_TYPE__KM);
+   psp_ring_stop(psp, PSP_RING_TYPE__KM); /* should not destroy 
ring, only stop */
goto skip_memalloc;
}
 
-- 
2.7.4

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


RE: [PATCH 2/2] drm/amdgpu/psp: Fix can't detect psp INVOKE command failed

2018-12-17 Thread Yu, Xiangliang
Anyone to help reviewing?

Thanks!
-Original Message-
From: amd-gfx  On Behalf Of Xiangliang Yu
Sent: Thursday, December 13, 2018 3:42 PM
To: amd-gfx@lists.freedesktop.org
Cc: Yu, Xiangliang 
Subject: [PATCH 2/2] drm/amdgpu/psp: Fix can't detect psp INVOKE command failed

There isn't ucode when executing INVOKE command, so current code can't check 
the failure of INVOKE command.

Remove the ucode check.

Signed-off-by: Xiangliang Yu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 2f126ea7..7f5ce37 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -140,10 +140,13 @@ psp_cmd_submit_buf(struct psp_context *psp,
while (*((unsigned int *)psp->fence_buf) != index)
msleep(1);
 
-   /* the status field must be 0 after FW is loaded */
-   if (ucode && psp->cmd_buf_mem->resp.status) {
-   DRM_ERROR("failed loading with status (%d) and ucode id (%d)\n",
- psp->cmd_buf_mem->resp.status, ucode->ucode_id);
+   /* the status field must be 0 after psp command completion */
+   if (psp->cmd_buf_mem->resp.status) {
+   if (ucode)
+   DRM_ERROR("failed to load ucode id (%d) ",
+ ucode->ucode_id);
+   DRM_ERROR("psp command failed and response status is (%d)\n",
+ psp->cmd_buf_mem->resp.status);
return -EINVAL;
}
 
--
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 1/2] drm/amdgpu/psp_v3_1: Get psp fw version through reading register

2018-12-12 Thread Yu, Xiangliang
This series reviewed by: Xiangliang Yu 

-Original Message-
From: amd-gfx  On Behalf Of Emily Deng
Sent: Wednesday, December 12, 2018 5:37 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deng, Emily 
Subject: [PATCH 1/2] drm/amdgpu/psp_v3_1: Get psp fw version through reading 
register

If PSP FW is running already, driver will not load PSP FW again and skip it. So 
psp fw version is not correct if reading it from FW binary file, need to get 
right version from register.

Signed-off-by: Emily Deng 
---
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c 
b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
index 7357fd5..79694ff 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
@@ -240,8 +240,11 @@ static int psp_v3_1_bootloader_load_sos(struct psp_context 
*psp)
 * are already been loaded.
 */
sol_reg = RREG32_SOC15(MP0, 0, mmMP0_SMN_C2PMSG_81);
-   if (sol_reg)
+   if (sol_reg) {
+   psp->sos_fw_version = RREG32_SOC15(MP0, 0, mmMP0_SMN_C2PMSG_58);
+   printk("sos fw version = 0x%x.\n", psp->sos_fw_version);
return 0;
+   }
 
/* Wait for bootloader to signify that is ready having bit 31 of 
C2PMSG_35 set to 1 */
ret = psp_wait_for(psp, SOC15_REG_OFFSET(MP0, 0, mmMP0_SMN_C2PMSG_35),
--
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 v2] drm/amdgpu: Clean sdma wptr register when only enable wptr polling

2018-03-06 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Emily Deng
> Sent: Wednesday, March 07, 2018 9:52 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deng, Emily <emily.d...@amd.com>
> Subject: [PATCH v2] drm/amdgpu: Clean sdma wptr register when only
> enable wptr polling
> 
> The sdma wptr polling memory is not fast enough, then the sdma wptr
> register will be random, and not equal to sdma rptr, which will cause sdma
> engine hang when load driver, so clean up the sdma wptr directly to fix this
> issue.
> 
> v2:add comment above the code and correct coding style
> Signed-off-by: Emily Deng <emily.d...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> index 521978c..89ec17c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> @@ -719,14 +719,17 @@ static int sdma_v3_0_gfx_resume(struct
> amdgpu_device *adev)
>   WREG32(mmSDMA0_GFX_RB_WPTR_POLL_ADDR_HI +
> sdma_offsets[i],
>  upper_32_bits(wptr_gpu_addr));
>   wptr_poll_cntl =
> RREG32(mmSDMA0_GFX_RB_WPTR_POLL_CNTL + sdma_offsets[i]);
> - if (ring->use_pollmem)
> + if (ring->use_pollmem) {
> + /*wptr polling is not enogh fast, directly clean the
> wptr register */
> + WREG32(mmSDMA0_GFX_RB_WPTR +
> sdma_offsets[i], 0);
>   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl,
> 
> SDMA0_GFX_RB_WPTR_POLL_CNTL,
>  ENABLE, 1);
> - else
> + } else {
>   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl,
> 
> SDMA0_GFX_RB_WPTR_POLL_CNTL,
>  ENABLE, 0);
> + }
>   WREG32(mmSDMA0_GFX_RB_WPTR_POLL_CNTL +
> sdma_offsets[i], wptr_poll_cntl);
> 
>   /* enable DMA RB */
> --
> 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: Clean sdma wptr register when only enable wptr polling

2018-03-06 Thread Yu, Xiangliang
Better to add comment above the code.

Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Emily Deng
> Sent: Tuesday, March 06, 2018 5:17 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deng, Emily <emily.d...@amd.com>
> Subject: [PATCH] drm/amdgpu: Clean sdma wptr register when only enable
> wptr polling
> 
> The sdma wptr polling memory is not fast enough, then the sdma wptr
> register will be random, and not equal to sdma rptr, which will cause sdma
> engine hang when load driver, so clean up the sdma wptr directly to fix this
> issue.
> 
> Signed-off-by: Emily Deng <emily.d...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> index 521978c..2a27928 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> @@ -719,11 +719,12 @@ static int sdma_v3_0_gfx_resume(struct
> amdgpu_device *adev)
>   WREG32(mmSDMA0_GFX_RB_WPTR_POLL_ADDR_HI +
> sdma_offsets[i],
>  upper_32_bits(wptr_gpu_addr));
>   wptr_poll_cntl =
> RREG32(mmSDMA0_GFX_RB_WPTR_POLL_CNTL + sdma_offsets[i]);
> - if (ring->use_pollmem)
> + if (ring->use_pollmem) {
> + WREG32(mmSDMA0_GFX_RB_WPTR +
> sdma_offsets[i], 0);
>   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl,
> 
> SDMA0_GFX_RB_WPTR_POLL_CNTL,
>  ENABLE, 1);
> - else
> + } else
>   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl,
> 
> SDMA0_GFX_RB_WPTR_POLL_CNTL,
>  ENABLE, 0);
> --
> 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] Revert "drm/amdgpu/gfx8: Fix compute ring failure after resetting"

2018-01-31 Thread Yu, Xiangliang
Ok, thanks!


From: Grodzovsky, Andrey
Sent: Thursday, February 01, 2018 12:59 AM
To: Yu, Xiangliang <xiangliang...@amd.com>; amd-gfx@lists.freedesktop.org; 
Deng, Emily <emily.d...@amd.com>
Cc: Deucher, Alexander <alexander.deuc...@amd.com>; Koenig, Christian 
<christian.koe...@amd.com>; Wu, Haisheng <haisheng...@amd.com>
Subject: Re: [PATCH] Revert "drm/amdgpu/gfx8: Fix compute ring failure after 
resetting"




On 01/25/2018 11:33 PM, Yu, Xiangliang wrote:

You can add amdgpu_sriov_vf() check to avoid breaking sriov.

+ Haisheng

As found out after more debugging  and discussion with Haisheng from HW team, 
the sequence introduced by this change is is wrong, it causes compute rings 
test failure because "the ring buffer has to be filled with valid packets (such 
as NOPs) first before submitting MAP_QUEUEs packet into KIQ. Once a compute 
engine is mapped, it will immediately execute the ring buffer if the RTPR is 
not equal to the WTPR from the MQD. It could lead to engine hang if the ring 
buffer filled with random data."

Hence we would like to revert this change in amd-staging-drm-next and continue 
investigation on the SR-IOV side why the correct programming sequence doesn't 
work there. I myself currently working on setting up SR-IOV setup to take a 
look at that.

Thanks,
Andrey






-Original Message-

From: Grodzovsky, Andrey

Sent: Friday, January 26, 2018 11:29 AM

To: Yu, Xiangliang <xiangliang...@amd.com><mailto:xiangliang...@amd.com>; amd-

g...@lists.freedesktop.org<mailto:g...@lists.freedesktop.org>

Cc: Deucher, Alexander 
<alexander.deuc...@amd.com><mailto:alexander.deuc...@amd.com>; Koenig, Christian

<christian.koe...@amd.com><mailto:christian.koe...@amd.com>

Subject: Re: [PATCH] Revert "drm/amdgpu/gfx8: Fix compute ring failure

after resetting"



No, just bare metal, I assumed your problem was with compute ring test

failure which I didn't see. Can you please recheck if reverting this still 
failing

on SRIOV ?

If so we obviously need to keep looking how to fix it.



Thanks,

Andrey





From: Yu, Xiangliang

Sent: 25 January 2018 20:59:45

To: Grodzovsky, Andrey; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>

Cc: Deucher, Alexander; Grodzovsky, Andrey; Koenig, Christian

Subject: RE: [PATCH] Revert "drm/amdgpu/gfx8: Fix compute ring failure

after resetting"



Did you test reset case in sriov?



-Original Message-

From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf

Of Andrey Grodzovsky

Sent: Friday, January 26, 2018 7:07 AM

To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>

Cc: Deucher, Alexander 
<alexander.deuc...@amd.com><mailto:alexander.deuc...@amd.com>; Grodzovsky,

Andrey

<andrey.grodzov...@amd.com><mailto:andrey.grodzov...@amd.com>; Yu, Xiangliang

<xiangliang...@amd.com><mailto:xiangliang...@amd.com>;

Koenig, Christian <christian.koe...@amd.com><mailto:christian.koe...@amd.com>

Subject: [PATCH] Revert "drm/amdgpu/gfx8: Fix compute ring failure

after resetting"



This reverts commit 75737cb4eb78c7f185e4700b4aa20cf7a3381aca.



Fixes GFX ring test failure after HW reset.

No compute ring test failures were observed with the change reverted.

So seems like whatever problem that change was addressing is not

present anymore.



Signed-off-by: Andrey Grodzovsky 
<andrey.grodzov...@amd.com><mailto:andrey.grodzov...@amd.com>

---

 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 10 +++---

 1 file changed, 3 insertions(+), 7 deletions(-)



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

b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c

index 1207f36..8a65b53 100644

--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c

+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c

@@ -4847,6 +4847,9 @@ static int gfx_v8_0_kcq_init_queue(struct

amdgpu_ring *ring)

  /* reset MQD to a clean status */

  if (adev->gfx.mec.mqd_backup[mqd_idx])

  memcpy(mqd, adev-

gfx.mec.mqd_backup[mqd_idx], sizeof(struct vi_mqd_allocation));

+ /* reset ring buffer */

+ ring->wptr = 0;

+ amdgpu_ring_clear_ring(ring);

  } else {

  amdgpu_ring_clear_ring(ring);

  }

@@ -4921,13 +4924,6 @@ static int gfx_v8_0_kiq_resume(struct

amdgpu_device *adev)

  /* Test KCQs */

  for (i = 0; i < adev->gfx.num_compute_rings; i++) {

  ring = >gfx.compute_ring[i];

- if (adev->in_gpu_reset) {

- /* move reset ring buffer to here to workaround

-  * compute ring test failed

-  */

- ring->wptr = 0;

- amdgpu_ring_clear_ring(ring);

- }

  ring

RE: [PATCH] Revert "drm/amdgpu/gfx8: Fix compute ring failure after resetting"

2018-01-25 Thread Yu, Xiangliang
You can add amdgpu_sriov_vf() check to avoid breaking sriov.

> -Original Message-
> From: Grodzovsky, Andrey
> Sent: Friday, January 26, 2018 11:29 AM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Cc: Deucher, Alexander <alexander.deuc...@amd.com>; Koenig, Christian
> <christian.koe...@amd.com>
> Subject: Re: [PATCH] Revert "drm/amdgpu/gfx8: Fix compute ring failure
> after resetting"
> 
> No, just bare metal, I assumed your problem was with compute ring test
> failure which I didn't see. Can you please recheck if reverting this still 
> failing
> on SRIOV ?
> If so we obviously need to keep looking how to fix it.
> 
> Thanks,
> Andrey
> 
> 
> From: Yu, Xiangliang
> Sent: 25 January 2018 20:59:45
> To: Grodzovsky, Andrey; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander; Grodzovsky, Andrey; Koenig, Christian
> Subject: RE: [PATCH] Revert "drm/amdgpu/gfx8: Fix compute ring failure
> after resetting"
> 
> Did you test reset case in sriov?
> 
> > -Original Message-
> > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Andrey Grodzovsky
> > Sent: Friday, January 26, 2018 7:07 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Deucher, Alexander <alexander.deuc...@amd.com>; Grodzovsky,
> Andrey
> > <andrey.grodzov...@amd.com>; Yu, Xiangliang
> <xiangliang...@amd.com>;
> > Koenig, Christian <christian.koe...@amd.com>
> > Subject: [PATCH] Revert "drm/amdgpu/gfx8: Fix compute ring failure
> > after resetting"
> >
> > This reverts commit 75737cb4eb78c7f185e4700b4aa20cf7a3381aca.
> >
> > Fixes GFX ring test failure after HW reset.
> > No compute ring test failures were observed with the change reverted.
> > So seems like whatever problem that change was addressing is not
> > present anymore.
> >
> > Signed-off-by: Andrey Grodzovsky <andrey.grodzov...@amd.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > index 1207f36..8a65b53 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > @@ -4847,6 +4847,9 @@ static int gfx_v8_0_kcq_init_queue(struct
> > amdgpu_ring *ring)
> >   /* reset MQD to a clean status */
> >   if (adev->gfx.mec.mqd_backup[mqd_idx])
> >   memcpy(mqd, adev-
> > >gfx.mec.mqd_backup[mqd_idx], sizeof(struct vi_mqd_allocation));
> > + /* reset ring buffer */
> > + ring->wptr = 0;
> > + amdgpu_ring_clear_ring(ring);
> >   } else {
> >   amdgpu_ring_clear_ring(ring);
> >   }
> > @@ -4921,13 +4924,6 @@ static int gfx_v8_0_kiq_resume(struct
> > amdgpu_device *adev)
> >   /* Test KCQs */
> >   for (i = 0; i < adev->gfx.num_compute_rings; i++) {
> >   ring = >gfx.compute_ring[i];
> > - if (adev->in_gpu_reset) {
> > - /* move reset ring buffer to here to workaround
> > -  * compute ring test failed
> > -  */
> > - ring->wptr = 0;
> > - amdgpu_ring_clear_ring(ring);
> > - }
> >   ring->ready = true;
> >   r = amdgpu_ring_test_ring(ring);
> >   if (r)
> > --
> > 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] Release the mutex hold before backtracing for not supported mxgpu.

2017-12-19 Thread Yu, Xiangliang
> This patch releases the mutex held soon before entering the initialization
> function in case the device doesn't support mxgpu.
> 
> Signed-off-by: José Pekkarinen 
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index c25a831f94ec..cac1d8b003e6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -307,6 +307,7 @@ void xgpu_vi_init_golden_registers(struct
> amdgpu_device *adev)
> 
> xgpu_tonga_golden_common_all));
>   break;
>   default:
> + mutex_unlock(>grbm_idx_mutex);
>   BUG_ON("Doesn't support chip type.\n");
>   break;
>   }

The release mutex in here has no meaning as kernel will hang later. And Alex 
has submitted patch to check ASIC IP during detecting SRIOV, so we can't see 
the case anymore. Please drop the patch.

Thanks!

> --
> 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 1/2] drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji

2017-12-19 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Alex Deucher
> Sent: Tuesday, December 19, 2017 11:07 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander <alexander.deuc...@amd.com>
> Subject: [PATCH 1/2] drm/amdgpu: only check
> mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji
> 
> We only support SR-IOV on tonga/fiji.  Don't check this register on other VI
> parts.
> 
> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/vi.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index d9bb26322850..c59b37365e4d
> 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -449,14 +449,19 @@ static bool vi_read_bios_from_rom(struct
> amdgpu_device *adev,
> 
>  static void vi_detect_hw_virtualization(struct amdgpu_device *adev)  {
> - uint32_t reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
> - /* bit0: 0 means pf and 1 means vf */
> - /* bit31: 0 means disable IOV and 1 means enable */
> - if (reg & 1)
> - adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
> -
> - if (reg & 0x8000)
> - adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
> + uint32_t reg = 0;
> +
> + if (adev->asic_type == CHIP_TONGA ||
> + adev->asic_type == CHIP_FIJI) {
> +reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
> +/* bit0: 0 means pf and 1 means vf */
> +/* bit31: 0 means disable IOV and 1 means enable */
> +if (reg & 1)
> +adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
> +
> +if (reg & 0x8000)
> +adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
> + }
> 
>   if (reg == 0) {
>   if (is_virtual_machine()) /* passthrough mode exclus sr-iov
> mode */
> --
> 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: Topaz mistakenly reported as vf

2017-12-19 Thread Yu, Xiangliang
>   Also, I noticed the following patch in case you can consider it for
> upstream.

Please send it to amd-gfx mailist for code review.

> 
>   Best regards.
> 
>   José.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: Topaz mistakenly reported as vf

2017-12-19 Thread Yu, Xiangliang
We can add ASIC check in vi_detect_hw_virtualization function to avoid to entry 
error path.
I'll submit patch later.

Thanks!

> -Original Message-
> From: José Pekkarinen [mailto:jose.pekkari...@canonical.com]
> Sent: Tuesday, December 19, 2017 3:27 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> <alexander.deuc...@amd.com>; Koenig, Christian
> <christian.koe...@amd.com>
> Subject: Re: Topaz mistakenly reported as vf
> 
> On Tuesday, 19 December 2017 09:19:02 EET Yu, Xiangliang wrote:
> > Topaz doesn't support SRIOV.
> >
> 
>   Hi Xiangliang,
> 
>   Allow me to ask for some attention, as I'm trying to say that given
> that Topaz is not having support, amdgpu_sriov_vf(adev) may return false
> and ignore the vi.c code path. Instead of it, it enters the code path and
> reaches the BUG_ON that states this is not supported.
> 
>   Thanks for coming back!
> 
>   José.
> 

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


RE: Topaz mistakenly reported as vf

2017-12-18 Thread Yu, Xiangliang
Topaz doesn't support SRIOV.


> -Original Message-
> From: José Pekkarinen [mailto:jose.pekkari...@canonical.com]
> Sent: Tuesday, December 19, 2017 3:12 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> <alexander.deuc...@amd.com>; Koenig, Christian
> <christian.koe...@amd.com>
> Subject: Re: Topaz mistakenly reported as vf
> 
> On Sunday, 17 December 2017 21:20:49 EET José Pekkarinen wrote:
> > Hi,
> >
> > I hit an issue that seems to be a topaz discrete vga reporting it's a
> > virtual function when my laptop is running on the battery. I received
> > the following bactrace:
> >
> > Dec 17 11:17:28 bee kernel: [   31.976810] kernel BUG at
> > drivers/gpu/drm/amd/ amdgpu/mxgpu_vi.c:310!
> > Dec 17 11:17:28 bee kernel: [   31.976815] invalid opcode:  [#1] SMP
> > Dec 17 11:17:28 bee kernel: [   31.976831] Modules linked in: vfio_pci
> > vfio_virqfd udl loop bfq arc4 iwlmvm mac80211 kvmgt vfio_mdev
> > amdgpu(+) mdev
> > vfio_iommu_type1 vfio i915 uvcvideo x86_pkg_temp_thermal
> > videobuf2_vmalloc videobuf2_memo ps videobuf2_v4l2 intel_powerclamp
> > videobuf2_core coretemp videodev kvm_intel kvm i2c_algo_bit
> > rtsx_pci_sdmmc drm_kms_helper joydev mmc_core media mousedev
> > rtsx_pci_ms btusb btrtl btbcm memstick ttm drm wmi_bmof hci_uart
> > btintel bluetoot h iwlwifi snd_hda_intel snd_hda_codec cfg80211
> > irqbypass crc32c_intel ghash_clmulni_intel intel_cstate snd_hwdep
> > intel_uncore snd_hda_core psmouse intel_rapl_perf rtsx_pci snd_pcm
> > efi_pstore evdev ideapad_laptop ac input_leds serio_raw e fivars
> > sparse_keymap intel_lpss_acpi battery thermal ecdh_generic wmi fan
> > syscopyarea snd_timer sysfillrect snd rfkill intel_lpss
> > Dec 17 11:17:28 bee kernel: [   31.977023]  video sysimgblt tpm_crb
> > soundcore button mfd_core i2c_hid i2c_i801 fb_sys_fops backlight
> > acpi_pad efivarfs unix dm_zero dm_thin_pool dm_persistent_data
> > dm_bio_prison dm_service_time dm_round_ro bin dm_queue_length
> > dm_multipath dm_log_userspace cn dm_flakey dm_delay xts aesni_intel
> > crypto_simd cryptd glue_helper aes_x86_64 cbc sha256_generic
> > scsi_transport_iscsi r8169 mii fuse xfs nfs lockd grace sunrpc fscache
> > ext4 mbcache jbd2  multipath linear raid10 raid1 raid0 dm_raid raid456
> > md_mod async_raid6_recov async_memcpy async_pq async_xor xor
> async_tx
> > raid6_pq libcrc32c dm_snapshot dm_bufio dm_crypt dm_mirror
> > dm_region_hash dm_log dm_mod dax hid_generic usbhid xhc i_pci
> xhci_hcd
> > ohci_hcd uhci_hcd usb_storage ehci_pci ehci_hcd usbcore usb_common
> > scsi_transport_fc sr_mod cdrom sg sd_mod ata_piix
> > Dec 17 11:17:28 bee kernel: [   31.977223]  ahci libahci sata_sx4
> > pata_oldpiix Dec 17 11:17:28 bee kernel: [   31.977239] CPU: 0 PID: 3698
> > Comm: udevd Not tainted 4.14.5 #10
> > Dec 17 11:17:28 bee kernel: [   31.977255] Hardware name: LENOVO
> 80UV/Lenovo
> > ideapad 510S-14IKB, BIOS 2SCN21WW(V2.01) 12/20/2016
> > Dec 17 11:17:28 bee kernel: [   31.977278] task: 880358b54280
> > task.stack: c900014dc000
> > Dec 17 11:17:28 bee kernel: [   31.977323] RIP:
> > 0010:xgpu_vi_init_golden_registers+0x56/0xa0 [amdgpu]
> > Dec 17 11:17:28 bee kernel: [   31.977341] RSP: 0018:c900014dfa08
> > EFLAGS: 00010293
> > Dec 17 11:17:28 bee kernel: [   31.977356] RAX: 000a RBX:
> > 88034004 RCX: 
> > Dec 17 11:17:28 bee kernel: [   31.977375] RDX: 880358b54280 RSI:
> > 0100 RDI: 88034004
> > Dec 17 11:17:28 bee kernel: [   31.977394] RBP: c900014dfa10 R08:
> > 88033c6dd198 R09: 
> > Dec 17 11:17:28 bee kernel: [   31.977413] R10: 880352c0aaa0 R11:
> > 0008 R12: 880340040458
> > Dec 17 11:17:28 bee kernel: [   31.977432] R13:  R14:
> >  R15: 88034004
> > Dec 17 11:17:28 bee kernel: [   31.977452] FS:  7fbfdd8c0780()
> > GS:88046ec0() knlGS:
> > Dec 17 11:17:28 bee kernel: [   31.977474] CS:  0010 DS:  ES:  CR0:
> > 80050033
> > Dec 17 11:17:28 bee kernel: [   31.977490] CR2: 55c3b48c1408 CR3:
> > 000358307003 CR4: 003606f0
> > Dec 17 11:17:28 bee kernel: [   31.977527] Call Trace:
> > Dec 17 11:17:28 bee kernel: [   31.977555]  vi_common_hw_init+0x77/0xe0
> > [amdgpu]
> > Dec 17 11:17:28 bee kernel: [   31.977584]
> amdgpu_device_init+0xc4b/0x14b0
> > [amdgpu]
> > Dec 17 11:17:28 bee kernel: [   31.977601]  ? kmem_cache_alloc_t

RE: [PATCH] drm/amdgpu/gfx8: Fix compute ring failure after resetting

2017-11-10 Thread Yu, Xiangliang
> The ring clear is already before "ring test", you patch just postpone the ring
> clear to an even later point, Do you know the root cause of your fix ?

Yes, just postpone it. Still can't find the root cause and the issue only 
happen on gfx8.
I'm ok if you can find better solution.
 
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Xiangliang.Yu
> Sent: 2017年11月10日 14:52
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang <xiangliang...@amd.com>
> Subject: [PATCH] drm/amdgpu/gfx8: Fix compute ring failure after resetting
> 
> Do ring clear before ring test, otherwise compute ring test will fail after 
> gpu
> resetting.
> 
> Signed-off-by: Xiangliang.Yu <xiangliang...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index a74515a..a982919 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -4868,9 +4868,6 @@ static int gfx_v8_0_kcq_init_queue(struct
> amdgpu_ring *ring)
>   /* reset MQD to a clean status */
>   if (adev->gfx.mec.mqd_backup[mqd_idx])
>   memcpy(mqd, adev-
> >gfx.mec.mqd_backup[mqd_idx], sizeof(struct vi_mqd_allocation));
> - /* reset ring buffer */
> - ring->wptr = 0;
> - amdgpu_ring_clear_ring(ring);
>   } else {
>   amdgpu_ring_clear_ring(ring);
>   }
> @@ -4945,6 +4942,11 @@ static int gfx_v8_0_kiq_resume(struct
> amdgpu_device *adev)
>   /* Test KCQs */
>   for (i = 0; i < adev->gfx.num_compute_rings; i++) {
>   ring = >gfx.compute_ring[i];
> + if (adev->in_gpu_reset) {
> + /* reset ring buffer */
> + ring->wptr = 0;
> + amdgpu_ring_clear_ring(ring);
> + }
>   ring->ready = true;
>   r = amdgpu_ring_test_ring(ring);
>   if (r)
> --
> 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 gpu recover missing skipping

2017-11-07 Thread Yu, Xiangliang
Reviewed-and-tested-By: Xiangliang Yu <xiangliang...@amd.com>


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, November 08, 2017 2:39 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH] drm/amdgpu:fix gpu recover missing skipping
> 
> if app close CTX right after IB submit, gpu recover will failed to find out 
> the
> entity/ctx behind the guilty job thus lead to bad job skipping in scheduler
> failed
> 
> to fix this corner case just move the job->karma increasing out of the
> condition that the backing entity was found that way the job itself will be
> "guilty" anyway
> 
> Change-Id: Ia30f02df9297a343d6d8dace496e237827dd1548
> Signed-off-by: Monk Liu <monk@amd.com>
> ---
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> index 7aa6455..720fd1b 100644
> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> @@ -464,6 +464,7 @@ void amd_sched_hw_job_reset(struct
> amd_gpu_scheduler *sched, struct amd_sched_jo
>   spin_unlock(>job_list_lock);
> 
>   if (bad) {
> + atomic_inc(>karma);
>   /* don't increase @bad's karma if it's from KERNEL RQ,
>* becuase sometimes GPU hang would cause kernel jobs
> (like VM updating jobs)
>* corrupt but keep in mind that kernel jobs always
> considered good.
> @@ -474,7 +475,7 @@ void amd_sched_hw_job_reset(struct
> amd_gpu_scheduler *sched, struct amd_sched_jo
>   spin_lock(>lock);
>   list_for_each_entry_safe(entity, tmp, >entities,
> list) {
>   if (bad->s_fence->scheduled.context ==
> entity->fence_context) {
> - if (atomic_inc_return(>karma) > bad-
> >sched->hang_limit)
> + if (atomic_read(>karma) > bad-
> >sched->hang_limit)
>   if (entity->guilty)
>   atomic_set(entity-
> >guilty, 1);
>   break;
> --
> 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 gpu recover missing skipping(v2)

2017-11-07 Thread Yu, Xiangliang
Reviewed-By: Xiangliang Yu <xiangliang...@amd.com>


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, November 08, 2017 3:08 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH] drm/amdgpu:fix gpu recover missing skipping(v2)
> 
> if app close CTX right after IB submit, gpu recover will fail to find out the
> entity behind this guilty job thus lead to no job skipping for this guilty 
> job.
> 
> to fix this corner case just move the increasement of
> job->karma out of the entity iteration.
> 
> v2:
> only do karma increasment if bad->s_priority != KERNEL because we always
> consider KERNEL job be correct and always want to recover an unfinished
> kernel job (sometimes kernel job is interrupted by VF FLR or other GPU hang
> event)
> 
> Change-Id: I33e9e959e182d7e002a2108e565cb898acac4f9c
> Signed-off-by: Monk Liu <monk@amd.com>
> ---
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> index 7aa6455..c999026 100644
> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> @@ -463,7 +463,8 @@ void amd_sched_hw_job_reset(struct
> amd_gpu_scheduler *sched, struct amd_sched_jo
>   }
>   spin_unlock(>job_list_lock);
> 
> - if (bad) {
> + if (bad && bad->s_priority != AMD_SCHED_PRIORITY_KERNEL) {
> + atomic_inc(>karma);
>   /* don't increase @bad's karma if it's from KERNEL RQ,
>* becuase sometimes GPU hang would cause kernel jobs
> (like VM updating jobs)
>* corrupt but keep in mind that kernel jobs always
> considered good.
> @@ -474,7 +475,7 @@ void amd_sched_hw_job_reset(struct
> amd_gpu_scheduler *sched, struct amd_sched_jo
>   spin_lock(>lock);
>   list_for_each_entry_safe(entity, tmp, >entities,
> list) {
>   if (bad->s_fence->scheduled.context ==
> entity->fence_context) {
> - if (atomic_inc_return(>karma) > bad-
> >sched->hang_limit)
> + if (atomic_read(>karma) > bad-
> >sched->hang_limit)
>   if (entity->guilty)
>   atomic_set(entity-
> >guilty, 1);
>   break;
> --
> 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/virt: don't dereference undefined 'module' struct

2017-11-03 Thread Yu, Xiangliang
Reviewed-By: Xiangliang Yu <xiangliang...@amd.com>

Thanks!

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Thursday, November 02, 2017 7:26 PM
> To: Deucher, Alexander <alexander.deuc...@amd.com>; Koenig, Christian
> <christian.koe...@amd.com>
> Cc: Arnd Bergmann <a...@arndb.de>; David Airlie <airl...@linux.ie>; Liu,
> Monk <monk@amd.com>; Yu, Xiangliang <xiangliang...@amd.com>;
> Chen, Horace <horace.c...@amd.com>; amd-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu/virt: don't dereference undefined 'module'
> struct
> 
> Accessing the THIS_MODULE directly is only possible when modules are
> enabled, otherwise we get a build failure:
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c: In function
> 'amdgpu_virt_init_data_exchange':
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:20: error: dereferencing
> pointer to incomplete type 'struct module'
> 
> Further, THIS_MODULE is NULL when the driver is built-in, so the code would
> likely cause a NULL pointer dereference.
> 
> This adds an #ifdef check to avoid the compile-time error, plus a NULL
> pointer check before dereferencing THIS_MODULE. It might be better to find
> a way to avoid using the module version altogether.
> 
> Fixes: 2dc8f81e4f82 ("drm/amdgpu: SR-IOV data exchange between PF")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index e97f80f86005..4e4a476593e8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -328,9 +328,11 @@ void amdgpu_virt_init_data_exchange(struct
> amdgpu_device *adev)
>   sizeof(amdgim_vf2pf_info));
>   AMDGPU_FW_VRAM_VF2PF_READ(adev,
> driver_version,
>   );
> +#ifdef MODULE
>   if (THIS_MODULE->version != NULL)
>   strcpy(str, THIS_MODULE->version);
>   else
> +#endif
>   strcpy(str, "N/A");
>   AMDGPU_FW_VRAM_VF2PF_WRITE(adev,
> driver_cert,
>   0);
> --
> 2.9.0

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


RE: [PATCH 1/2] drm/amdgpu: return error when sriov access requests get timeout

2017-10-31 Thread Yu, Xiangliang
>@@ -450,7 +450,7 @@ static int xgpu_vi_send_access_requests(struct 
>amdgpu_device *adev,
>   pr_err("Doesn't get ack from pf, continue\n");

Why don't return error in this place?

 >  }
 >
>-  return 0;
>+  return r;
 >}
 
 static int xgpu_vi_request_reset(struct amdgpu_device *adev)
-- 
2.9.5

___
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/2] drm/amdgpu: return error when sriov access requests get timeout (v2)

2017-10-31 Thread Yu, Xiangliang
Reviewed-By: Xiangliang Yu <xiangliang...@amd.com>


-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Pixel 
Ding
Sent: Tuesday, October 31, 2017 4:17 PM
To: amd-gfx@lists.freedesktop.org; Yu, Xiangliang <xiangliang...@amd.com>
Cc: Ding, Pixel <pixel.d...@amd.com>
Subject: [PATCH 1/2] drm/amdgpu: return error when sriov access requests get 
timeout (v2)

From: pding <pixel.d...@amd.com>

v2:
 - readable

Reported-by: Sun Gary <gary@amd.com>
Signed-off-by: pding <pixel.d...@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c 
b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
index 818ec0f..2b435c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
@@ -446,8 +446,10 @@ static int xgpu_vi_send_access_requests(struct 
amdgpu_device *adev,
request == IDH_REQ_GPU_FINI_ACCESS ||
request == IDH_REQ_GPU_RESET_ACCESS) {
r = xgpu_vi_poll_msg(adev, IDH_READY_TO_ACCESS_GPU);
-   if (r)
-   pr_err("Doesn't get ack from pf, continue\n");
+   if (r) {
+   pr_err("Doesn't get ack from pf, give up\n");
+   return r;
+   }
}
 
return 0;
-- 
2.9.5

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


RE: [PATCH 2/2] drm/amdgpu: retry init if exclusive mode request is failed

2017-10-31 Thread Yu, Xiangliang
RB-by: Xiangliang Yu <xiangliang...@amd.com>


-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Pixel 
Ding
Sent: Tuesday, October 31, 2017 3:11 PM
To: amd-gfx@lists.freedesktop.org
Cc: Ding, Pixel <pixel.d...@amd.com>
Subject: [PATCH 2/2] drm/amdgpu: retry init if exclusive mode request is failed

From: pding <pixel.d...@amd.com>

This is caused of that hypervisor fails to handle request, one known issue is 
MMIO unblocking timeout. In theory we can retry init here.

Signed-off-by: pding <pixel.d...@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index daa2098..ef01aa3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1625,7 +1625,7 @@ static int amdgpu_early_init(struct amdgpu_device *adev)
if (amdgpu_sriov_vf(adev)) {
r = amdgpu_virt_request_full_gpu(adev, true);
if (r)
-   return r;
+   return -EAGAIN;
}
 
for (i = 0; i < adev->num_ip_blocks; i++) {
--
2.9.5

___
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: right shift 2 bits for SDMA_GFX_RB_WPTR_POLL_ADDR_LO

2017-09-25 Thread Yu, Xiangliang
RB: Xiangliang Yu <xiangliang...@amd.com>


-Original Message-
From: Ding, Pixel 
Sent: Monday, September 25, 2017 2:42 PM
To: Liu, Monk <monk@amd.com>; amd-gfx@lists.freedesktop.org; Min, Frank 
<frank@amd.com>; Deucher, Alexander <alexander.deuc...@amd.com>; Yu, 
Xiangliang <xiangliang...@amd.com>
Subject: Re: [PATCH] drm/amdgpu: right shift 2 bits for 
SDMA_GFX_RB_WPTR_POLL_ADDR_LO

Hi Monk,

The world switch gets immediately fail. According to Xiangliang’s comment, I 
think 17.50 also has this issue. Other G branch uses original patch from Frank, 
that doesn’t have this issue. Please confirm this.

Also refer to 
http://adcweb02.amd.com/orlvalid/regspec/web_regspec/vega11/regspec/vega11_chip/public/index.html

SDMA0_GFX_RB_WPTR_POLL_ADDR_LO
ADDR 31:2


I update a v2 patch for this. I think it must fail if you really overwrite the 
address to 31:0.

— 
Sincerely Yours,
Pixel







On 25/09/2017, 2:37 PM, "Liu, Monk" <monk@amd.com> wrote:

>Hold on,
>
>We didn't hit test fail without your patch, actually at least VEGA10 doesn't 
>have the issue you mentioned, 
>Can you elaborate what issue or test case you can fix with this patch ?
>Besides, please don't change anything on vega10 before you verified it 
>
>BR Monk
>
>-Original Message-
>From: Pixel Ding [mailto:pixel.d...@amd.com] 
>Sent: Monday, September 25, 2017 2:16 PM
>To: amd-gfx@lists.freedesktop.org; Ding, Pixel <pixel.d...@amd.com>; Min, 
>Frank <frank@amd.com>; Liu, Monk <monk@amd.com>; Deucher, Alexander 
><alexander.deuc...@amd.com>
>Subject: [PATCH] drm/amdgpu: right shift 2 bits for 
>SDMA_GFX_RB_WPTR_POLL_ADDR_LO
>
>Both Tonga and Vega register SPECs indicate that this registers only use 31:2 
>bits in DW. SRIOV test case immediately fails withtout this shift.
>
>Signed-off-by: Pixel Ding <pixel.d...@amd.com>
>---
> drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 2 +-  
> drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c 
>b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
>index 72f31cc..947f019 100644
>--- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
>+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
>@@ -714,7 +714,7 @@ static int sdma_v3_0_gfx_resume(struct amdgpu_device *adev)
>   wptr_gpu_addr = adev->wb.gpu_addr + (ring->wptr_offs * 4);
> 
>   WREG32(mmSDMA0_GFX_RB_WPTR_POLL_ADDR_LO + sdma_offsets[i],
>- lower_32_bits(wptr_gpu_addr));
>+ lower_32_bits(wptr_gpu_addr) >> 2);
>   WREG32(mmSDMA0_GFX_RB_WPTR_POLL_ADDR_HI + sdma_offsets[i],
>  upper_32_bits(wptr_gpu_addr));
>   wptr_poll_cntl = RREG32(mmSDMA0_GFX_RB_WPTR_POLL_CNTL + 
> sdma_offsets[i]); diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
> b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
>index c26d205..26d7f03 100644
>--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
>+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
>@@ -665,7 +665,7 @@ static int sdma_v4_0_gfx_resume(struct amdgpu_device *adev)
>   /* setup the wptr shadow polling */
>   wptr_gpu_addr = adev->wb.gpu_addr + (ring->wptr_offs * 4);
>   WREG32(sdma_v4_0_get_reg_offset(i, 
> mmSDMA0_GFX_RB_WPTR_POLL_ADDR_LO),
>- lower_32_bits(wptr_gpu_addr));
>+ lower_32_bits(wptr_gpu_addr) >> 2);
>   WREG32(sdma_v4_0_get_reg_offset(i, 
> mmSDMA0_GFX_RB_WPTR_POLL_ADDR_HI),
>  upper_32_bits(wptr_gpu_addr));
>   wptr_poll_cntl = RREG32(sdma_v4_0_get_reg_offset(i, 
> mmSDMA0_GFX_RB_WPTR_POLL_CNTL));
>--
>2.7.4
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH 14/18] drm/amdgpu: Fix amdgpu reload failure under SRIOV

2017-09-18 Thread Yu, Xiangliang
pci_enable_device will set power state to D0. This patch is just work around 
the issue, not address the root cause.


-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Alex 
Deucher
Sent: Tuesday, September 19, 2017 5:07 AM
To: Koenig, Christian 
Cc: Chen, Horace ; amd-gfx list 
; Liu, Monk 
Subject: Re: [PATCH 14/18] drm/amdgpu: Fix amdgpu reload failure under SRIOV

On Mon, Sep 18, 2017 at 5:31 AM, Christian König 
 wrote:
> Am 18.09.2017 um 08:11 schrieb Monk Liu:
>>
>> From: Horace Chen 
>>
>> Kernel will set the PCI power state to UNKNOWN after unloading, Since 
>> SRIOV has faked PCI config space so the UNKNOWN state will be kept 
>> forever.
>>
>> In driver reload if the power state is UNKNOWN then enabling msi will 
>> fail.
>>
>> forcely set it to D0 for SRIOV to fix this kernel flawness.
>>
>> Change-Id: I6a72d5fc9b653b21c3c98167515a511c5edeb91c
>> Signed-off-by: Horace Chen 
>> Signed-off-by: Monk Liu 
>
>
> Acked-by: Christian König , but better wait 
> for Alex to have a look as well on this before pushing it.
>

Seems reasonable to me barring Xiangliang's comment.
Acked-by: Alex Deucher 

> Christian.
>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 10 +-
>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
>> index 914c5bf..345406a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
>> @@ -229,7 +229,15 @@ int amdgpu_irq_init(struct amdgpu_device *adev)
>> adev->irq.msi_enabled = false;
>> if (amdgpu_msi_ok(adev)) {
>> -   int ret = pci_enable_msi(adev->pdev);
>> +   int ret;
>> +   if (amdgpu_sriov_vf(adev) &&
>> +   adev->pdev->current_state == PCI_UNKNOWN){
>> +   /* If pci power state is unknown on the SRIOV
>> platform,
>> +* it may be set in the remove device. We 
>> + need to
>> forcely
>> +* set it to D0 to enable the msi*/
>> +   adev->pdev->current_state = PCI_D0;
>> +   }
>> +   ret = pci_enable_msi(adev->pdev);
>> if (!ret) {
>> adev->irq.msi_enabled = true;
>> dev_info(adev->dev, "amdgpu: using MSI.\n");
>
>
>
> ___
> 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 14/18] drm/amdgpu: Fix amdgpu reload failure under SRIOV

2017-09-18 Thread Yu, Xiangliang
NAK, Tonga has no this problem, please keep the patch into internal branch for 
temporally.


-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Monk 
Liu
Sent: Monday, September 18, 2017 2:12 PM
To: amd-gfx@lists.freedesktop.org
Cc: Chen, Horace ; Liu, Monk 
Subject: [PATCH 14/18] drm/amdgpu: Fix amdgpu reload failure under SRIOV

From: Horace Chen 

Kernel will set the PCI power state to UNKNOWN after unloading, Since SRIOV has 
faked PCI config space so the UNKNOWN state will be kept forever.

In driver reload if the power state is UNKNOWN then enabling msi will fail.

forcely set it to D0 for SRIOV to fix this kernel flawness.

Change-Id: I6a72d5fc9b653b21c3c98167515a511c5edeb91c
Signed-off-by: Horace Chen 
Signed-off-by: Monk Liu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 914c5bf..345406a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -229,7 +229,15 @@ int amdgpu_irq_init(struct amdgpu_device *adev)
adev->irq.msi_enabled = false;
 
if (amdgpu_msi_ok(adev)) {
-   int ret = pci_enable_msi(adev->pdev);
+   int ret;
+   if (amdgpu_sriov_vf(adev) &&
+   adev->pdev->current_state == PCI_UNKNOWN){
+   /* If pci power state is unknown on the SRIOV platform,
+* it may be set in the remove device. We need to 
forcely
+* set it to D0 to enable the msi*/
+   adev->pdev->current_state = PCI_D0;
+   }
+   ret = pci_enable_msi(adev->pdev);
if (!ret) {
adev->irq.msi_enabled = true;
dev_info(adev->dev, "amdgpu: using MSI.\n");
--
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: Can you tell me which driver supports AMD's sriov?

2017-09-14 Thread Yu, Xiangliang
Need GPU hypervisor driver if supporting amdgpu SRIOV. Right now, we still 
doesn't upstream the hypervisor driver to kernel, but we have a plan to 
upstream it.


From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
maok...@126.com
Sent: Thursday, September 14, 2017 3:57 PM
To: amd-gfx 
Subject: Can you tell me which driver supports AMD's sriov?

hi,all:
Which patch begins to support sriov for amd graphics cards ? Graphics cards 
such as AMD FirePro s7150.
I tested a lot of systems that didn't support, such as centos7.2, 
centos7.3, unbuntu17.4.


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


RE: [PATCH] drm/amdkfd: fix bug device is not added to supported_devices

2017-08-23 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Wang 
Hongcheng
Sent: Wednesday, August 23, 2017 4:58 PM
To: amd-gfx@lists.freedesktop.org
Cc: Wang, Annie <annie.w...@amd.com>
Subject: [PATCH] drm/amdkfd: fix bug device is not added to supported_devices

Add Tonga passthrough device 0x6929 to kfd device table.

BUG:SWDEV-130471

Signed-off-by: Wang Hongcheng <annie.w...@amd.com>
---
 drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 68c6212..acee0aa 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -277,6 +277,7 @@ static const struct kfd_deviceid supported_devices[] = {
{ 0x6920, _device_info   },   /* Tonga */
{ 0x6921, _device_info   },   /* Tonga */
{ 0x6928, _device_info   },   /* Tonga */
+   { 0x6929, _device_info   },   /* Tonga */
{ 0x692B, _device_info   },   /* Tonga */
{ 0x692F, _vf_device_info   },/* Tonga vf */
{ 0x6938, _device_info   },   /* Tonga */
-- 
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 1/1] drm/ttm: Fix accounting error when fail to get pages for pool

2017-08-16 Thread Yu, Xiangliang
I mean I don't know if the patch can fix mem leak issue.

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Michel D?nzer
Sent: Wednesday, August 16, 2017 6:03 PM
To: Yu, Xiangliang <xiangliang...@amd.com>; Zhou, David(ChunMing) 
<david1.z...@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/1] drm/ttm: Fix accounting error when fail to get pages 
for pool

On 16/08/17 06:43 PM, Yu, Xiangliang wrote:
> I don’t know, but it is obvious issue. Later I’ll run test with the patch.

In the future, please test patches before submitting them for review. :)


-- 
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/1] drm/ttm: Fix accounting error when fail to get pages for pool

2017-08-16 Thread Yu, Xiangliang
I don’t know, but it is obvious issue. Later I’ll run test with the patch.

From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
zhoucm1
Sent: Wednesday, August 16, 2017 5:10 PM
To: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/1] drm/ttm: Fix accounting error when fail to get pages 
for pool


Fix memory leak of ttm kernel issue?

On 2017年08月16日 15:55, Christian König wrote:
CC stable?

Reviewed-by: Christian König 
<christian.koe...@amd.com><mailto:christian.koe...@amd.com>

Am 16.08.2017 um 09:25 schrieb Liu, Monk:

Reviewed-by: Monk Liu <monk@amd.com><mailto:monk@amd.com>


From: amd-gfx 
<amd-gfx-boun...@lists.freedesktop.org><mailto:amd-gfx-boun...@lists.freedesktop.org>
 on behalf of Xiangliang.Yu 
<xiangliang...@amd.com><mailto:xiangliang...@amd.com>
Sent: Wednesday, August 16, 2017 3:20:46 PM
To: a...@linux-foundation.org<mailto:a...@linux-foundation.org>; 
labb...@redhat.com<mailto:labb...@redhat.com>; 
dri-de...@lists.freedesktop.org<mailto:dri-de...@lists.freedesktop.org>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Yu, Xiangliang
Subject: [PATCH 1/1] drm/ttm: Fix accounting error when fail to get pages for 
pool

When fail to get needed page for pool, need to put allocated pages
into pool. But current code has a miscalculation of allocated pages,
correct it.

Signed-off-by: Xiangliang.Yu 
<xiangliang...@amd.com><mailto:xiangliang...@amd.com>
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index eeddc1e..8715998 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -615,7 +615,7 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool 
*pool,
 } else {
 pr_err("Failed to fill pool (%p)\n", pool);
 /* If we have any pages left put them to the pool. */
-   list_for_each_entry(p, >list, lru) {
+   list_for_each_entry(p, _pages, lru) {
 ++cpages;
 }
 list_splice(_pages, >list);
--
2.7.4

___
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<mailto:amd-gfx@lists.freedesktop.org>

https://lists.freedesktop.org/mailman/listinfo/amd-gfx






___

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 8/8] drm/amdgpu/sdma4: Enable sdma poll mem addr on vega10 for SRIOV

2017-07-25 Thread Yu, Xiangliang
Got it, I'll change it later.

Thanks!

> From: Frank Min 
>
> While doing flr on VFs, there is possibility to lost the doorbell 
> writing for sdma, so enable poll mem for sdma, then sdma fw would 
> check the pollmem holding wptr.
>
> Signed-off-by: Frank Min 
> Signed-off-by: Xiangliang.Yu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  3 +++
>  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 48 
> --
>  2 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index d287621..79d46fd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1208,6 +1208,9 @@ struct amdgpu_sdma_instance {
>
> struct amdgpu_ring  ring;
> boolburst_nop;
> +   struct amdgpu_bo*poll_mem_bo;
> +   uint64_t*poll_mem_cpuaddr;
> +   uint64_tpoll_mem_gpuaddr;
>  };
>
>  struct amdgpu_sdma {
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
> b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> index 591f3e7..563be32 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> @@ -35,6 +35,7 @@
>  #include "vega10/MMHUB/mmhub_1_0_offset.h"
>  #include "vega10/MMHUB/mmhub_1_0_sh_mask.h"
>  #include "vega10/HDP/hdp_4_0_offset.h"
> +#include "vega10/NBIO/nbio_6_1_offset.h"
>  #include "raven1/SDMA0/sdma0_4_1_default.h"
>
>  #include "soc15_common.h"
> @@ -287,6 +288,7 @@ static uint64_t sdma_v4_0_ring_get_wptr(struct 
> amdgpu_ring *ring)
>   */
>  static void sdma_v4_0_ring_set_wptr(struct amdgpu_ring *ring)  {
> +   int i;
> struct amdgpu_device *adev = ring->adev;
>
> DRM_DEBUG("Setting write pointer\n"); @@ -303,6 +305,16 @@ 
> static void sdma_v4_0_ring_set_wptr(struct amdgpu_ring *ring)
> adev->wb.wb[ring->wptr_offs + 1] = upper_32_bits(ring->wptr 
> << 2);
> DRM_DEBUG("calling WDOORBELL64(0x%08x, 0x%016llx)\n",
> ring->doorbell_index, ring->wptr << 
> 2);
> +
> +   if (amdgpu_sriov_vf(adev)) {
> +   for (i = 0; i < adev->sdma.num_instances; i++) {
> +   if (>sdma.instance[i].ring == ring) {
> +   
> *adev->sdma.instance[i].poll_mem_cpuaddr = ring->wptr << 2;
> +   WREG32_NO_KIQ(SOC15_REG_OFFSET(NBIO, 
> 0,
> +  
> + mmBIF_BX_PF0_HDP_MEM_COHERENCY_FLUSH_CNTL), 0);

Please use nbio_v6_1_hdp_flush() here rather than open coding it.


> +   }
> +   }
> +   }
> WDOORBELL64(ring->doorbell_index, ring->wptr << 2);
> } else {
> int me = (ring == >adev->sdma.instance[0].ring) 
> ? 0 : 1; @@ -573,7 +585,7 @@ static void sdma_v4_0_enable(struct 
> amdgpu_device *adev, bool enable)  static int 
> sdma_v4_0_gfx_resume(struct amdgpu_device *adev)  {
> struct amdgpu_ring *ring;
> -   u32 rb_cntl, ib_cntl;
> +   u32 rb_cntl, ib_cntl, wptr_poll_addr_lo, wptr_poll_addr_hi, 
> + wptr_poll_cntl;
> u32 rb_bufsz;
> u32 wb_offset;
> u32 doorbell;
> @@ -687,6 +699,19 @@ static int sdma_v4_0_gfx_resume(struct 
> amdgpu_device *adev)
>
> if (adev->mman.buffer_funcs_ring == ring)
> amdgpu_ttm_set_active_vram_size(adev, 
> adev->mc.real_vram_size);
> +
> +   if (amdgpu_sriov_vf(adev)) {
> +   wptr_poll_cntl = RREG32(sdma_v4_0_get_reg_offset(i, 
> mmSDMA0_GFX_RB_WPTR_POLL_CNTL));
> +   wptr_poll_addr_lo = 
> RREG32(sdma_v4_0_get_reg_offset(i, mmSDMA0_GFX_RB_WPTR_POLL_ADDR_LO));
> +   wptr_poll_addr_lo = REG_SET_FIELD(wptr_poll_addr_lo, 
> SDMA0_GFX_RB_WPTR_POLL_ADDR_LO, ADDR,
> +   
> lower_32_bits(adev->sdma.instance[i].poll_mem_gpuaddr) >> 2);
> +   wptr_poll_addr_hi = 
> upper_32_bits(adev->sdma.instance[i].poll_mem_gpuaddr);
> +   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl, 
> + SDMA0_GFX_RB_WPTR_POLL_CNTL, F32_POLL_ENABLE, 1);
> +
> +   WREG32(sdma_v4_0_get_reg_offset(i, 
> mmSDMA0_GFX_RB_WPTR_POLL_ADDR_LO), wptr_poll_addr_lo);
> +   WREG32(sdma_v4_0_get_reg_offset(i, 
> + mmSDMA0_GFX_RB_WPTR_POLL_ADDR_HI), wptr_poll_addr_hi);

No need to add a separate bo for this.  Just use the wb buffer like we do on 
gfx.  E.g.,

wptr_gpu_addr = adev->wb.gpu_addr + (ring->wptr_offs * 4);
WREG32_SOC15(GC, 0, mmCP_RB_WPTR_POLL_ADDR_LO, 
lower_32_bits(wptr_gpu_addr));
WREG32_SOC15(GC, 0, mmCP_RB_WPTR_POLL_ADDR_HI, 

RE: [PATCH] drm/amdgpu: reduce the time of reading VBIOS

2017-07-24 Thread Yu, Xiangliang
Ok, thanks!

-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de] 
Sent: Friday, July 21, 2017 10:12 PM
To: Yu, Xiangliang <xiangliang...@amd.com>; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: reduce the time of reading VBIOS

Am 21.07.2017 um 04:52 schrieb Xiangliang.Yu:
> From: Xiangliang Yu <xiangliang...@amd.com>
>
> Change ioremap mode from noncache to write combine and it will reduce 
> the read vbios time from 188ms to 8ms.

Nice improvement, but I think you need to improve the commit message a bit.

Changing the ioremap mode from noncache to write combine should actually not 
improve the read performance (reads are uncached in both modes).

I think this patch makes a difference because VRAM is usually marked write 
combined and so ioremap needs to change that for no good reason and that in 
turn takes quite some time.

I think you should write something like "Avoid changing the mapping mode of 
VRAM while reading the vbios from it, this reduce the time from".

>
> Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> Signed-off-by: Xiangliang.Yu <xiangliang...@amd.com>
You added the signed-off-by line twice, please fix this.

With that fixed and the commit message improved a bit the patch is
Reviewed-by: Christian König <christian.koe...@amd.com>.

Regards,
Christian.

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> index ea3a250..c21adf6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> @@ -104,7 +104,7 @@ static bool igp_read_bios_from_vram(struct 
> amdgpu_device *adev)
>   
>   adev->bios = NULL;
>   vram_base = pci_resource_start(adev->pdev, 0);
> - bios = ioremap(vram_base, size);
> + bios = ioremap_wc(vram_base, size);
>   if (!bios) {
>   return false;
>   }


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


RE: The amd-stagint-4.11 doen't contain the commit ab51ee31dda1a37b473074e402394f879c51d591 in amd-staging-4.9

2017-07-05 Thread Yu, Xiangliang
Please check it with Evan, I remember he remind us to switch to staing-4.11

From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Liu, 
Monk
Sent: Wednesday, July 05, 2017 11:55 AM
To: Deng, Emily ; Deucher, Alexander 

Cc: amd-gfx@lists.freedesktop.org
Subject: RE: The amd-stagint-4.11 doen't contain the commit 
ab51ee31dda1a37b473074e402394f879c51d591 in amd-staging-4.9

+ amd-gfx

We really need to understand why this commit is not shown in 4.11 staging, 
because we worry other patches may meet same issue, and cause regression

BR Monk

From: Deng, Emily
Sent: Tuesday, July 04, 2017 11:31 PM
To: Deucher, Alexander 
>; Liu, Monk 
>
Subject: The amd-stagint-4.11 doen't contain the commit 
ab51ee31dda1a37b473074e402394f879c51d591 in amd-staging-4.9

Hi Alex,
 Monk has submitted a commit ab51ee31dda1a37b473074e402394f879c51d591 in 
amd-staging-4.9, but amd-staging-4.11 doesn't contain it.
 So is there any reason to prevent the commit being port to 
amd-staging-4.11? Or just missed this commit?

Best Wishes,
Emily Deng

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


RE: [PATCH] drm/amdgpu: extend lock range for race condition when gpu reset

2017-06-16 Thread Yu, Xiangliang
Hi Hongbo,

I got soft lockup message as below when running valkan test with two VFs, and 
work fine if reverting this patch. Could you help check it when you feel free?

[ 1920.163455] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[deqp-vk:2175]
[ 1920.163459] Modules linked in: amdkfd amd_iommu_v2 amdgpu(OE) ttm 
drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt 
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep 
snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq crct10dif_pclmul 
crc32_pclmul ghash_clmulni_intel snd_seq_device snd_timer aesni_intel 
aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd serio_raw snd mac_hid 
soundcore i2c_piix4 binfmt_misc parport_pc ppdev sunrpc lp parport autofs4 
psmouse pata_acpi floppy
[ 1920.163482] CPU: 1 PID: 2175 Comm: deqp-vk Tainted: G   OE   
4.9.0-custom #1
[ 1920.163483] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 1920.163484] task: 880139c63a80 task.stack: c9000313c000
[ 1920.163485] RIP: 0010:[]  [] 
native_queued_spin_lock_slowpath+0x15/0x1a0
[ 1920.163491] RSP: 0018:c9000313f6d8  EFLAGS: 0202
[ 1920.163492] RAX: 0001 RBX: 88012f054d80 RCX: 
[ 1920.163492] RDX: 0001 RSI: 0001 RDI: 8801334899a8
[ 1920.163493] RBP: c9000313f6d8 R08:  R09: 0128
[ 1920.163493] R10: 01b9269bb35e R11: 0001 R12: 88012f054e28
[ 1920.163494] R13: 88012f054d80 R14: 8800369ecc00 R15: 880133482778
[ 1920.163495] FS:  7fc0cf438740() GS:88013fc8() 
knlGS:
[ 1920.163496] CS:  0010 DS:  ES:  CR0: 80050033
[ 1920.163496] CR2: 7fc0c5100fa0 CR3: 00013870d000 CR4: 001406e0
[ 1920.163500] Stack:
[ 1920.163500]  c9000313f6e8 811816ef c9000313f6f8 
817e1a10
[ 1920.163502]  c9000313f738 a03242c0 8800369ecc00 
0400
[ 1920.163503]  0001 88012f054d80 0002 
88012e831380
[ 1920.163505] Call Trace:
[ 1920.163509]  [] queued_spin_lock_slowpath+0xb/0xf
[ 1920.163513]  [] _raw_spin_lock+0x20/0x30
[ 1920.163562]  [] amdgpu_ttm_backend_unbind+0x50/0x1e0 
[amdgpu]
[ 1920.163567]  [] ttm_tt_unbind+0x1e/0x30 [ttm]
[ 1920.163570]  [] ttm_tt_destroy+0x17/0x60 [ttm]
[ 1920.163572]  [] ttm_bo_cleanup_memtype_use+0x30/0x70 [ttm]
[ 1920.163575]  [] ttm_bo_release+0x1ca/0x2a0 [ttm]
[ 1920.163578]  [] ttm_bo_unref+0x24/0x30 [ttm]
[ 1920.163580]  [] ttm_bo_pipeline_move+0x2a7/0x3a0 [ttm]
[ 1920.163599]  [] amdgpu_move_blit+0x1bc/0x260 [amdgpu]
[ 1920.163617]  [] amdgpu_bo_move+0xb9/0x230 [amdgpu]
[ 1920.163620]  [] ttm_bo_handle_move_mem+0x268/0x590 [ttm]
[ 1920.163623]  [] ? ttm_bo_mem_space+0x38d/0x440 [ttm]
[ 1920.163625]  [] ? __save_stack_trace+0x73/0xd0
[ 1920.163628]  [] ttm_bo_validate+0x114/0x130 [ttm]
[ 1920.163657]  [] ? amdgpu_cs_bo_validate.isra.5+0xb0/0xb0 
[amdgpu]
[ 1920.163675]  [] amdgpu_cs_bo_validate.isra.5+0x75/0xb0 
[amdgpu]
[ 1920.163693]  [] ? amdgpu_cs_bo_validate.isra.5+0xb0/0xb0 
[amdgpu]
[ 1920.163710]  [] amdgpu_cs_validate+0x49/0x1b0 [amdgpu]
[ 1920.163727]  [] ? amdgpu_cs_bo_validate.isra.5+0xb0/0xb0 
[amdgpu]
[ 1920.163743]  [] ? amdgpu_cs_bo_validate.isra.5+0xb0/0xb0 
[amdgpu]
[ 1920.163762]  [] amdgpu_vm_validate_level.isra.9+0x4f/0x90 
[amdgpu]
[ 1920.163791]  [] ? amdgpu_cs_bo_validate.isra.5+0xb0/0xb0 
[amdgpu]
[ 1920.163807]  [] amdgpu_vm_validate_level.isra.9+0x66/0x90 
[amdgpu]
[ 1920.163823]  [] ? amdgpu_cs_bo_validate.isra.5+0xb0/0xb0 
[amdgpu]
[ 1920.163840]  [] amdgpu_vm_validate_level.isra.9+0x66/0x90 
[amdgpu]
[ 1920.163856]  [] amdgpu_vm_validate_pt_bos+0x26/0x30 
[amdgpu]
[ 1920.163872]  [] amdgpu_cs_ioctl+0xca8/0x1490 [amdgpu]
[ 1920.163889]  [] drm_ioctl+0x32c/0x440 [drm]
[ 1920.163904]  [] ? amdgpu_cs_find_mapping+0xb0/0xb0 [amdgpu]
[ 1920.163906]  [] ? mem_cgroup_commit_charge+0x76/0xe0
[ 1920.163908]  [] ? page_add_new_anon_rmap+0x89/0xc0
[ 1920.163910]  [] ? 
lru_cache_add_active_or_unevictable+0x39/0xc0
[ 1920.163925]  [] amdgpu_drm_ioctl+0x4c/0x80 [amdgpu]
[ 1920.163927]  [] do_vfs_ioctl+0x96/0x5b0
[ 1920.163929]  [] ? __do_page_fault+0x267/0x4d0
[ 1920.163930]  [] SyS_ioctl+0x79/0x90
[ 1920.163932]  [] do_syscall_64+0x6e/0x180
[ 1920.163933]  [] entry_SYSCALL64_slow_path+0x25/0x25

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Friday, May 05, 2017 8:04 PM
To: Zhou, David(ChunMing) ; He, Hongbo 
; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: extend lock range for race condition when gpu 
reset

Reviewed-by: Christian König 

Am 05.05.2017 um 09:33 schrieb zhoucm1:
> Reviewed-by: Chunming Zhou 
>
> On 2017年05月05日 15:22, Roger.He wrote:
>> to cover below case:
>> 1. A 

RE: [PATCH] drm/amdgpu: correct clock info for SRIOV

2017-06-05 Thread Yu, Xiangliang
> > Currently, get clock info from default clk of pm if dpm is disable.
> > Buf SRIOV doesn't support dpm and pm, can't get anything from pm.
> > Only get clock info only from default clk of amdgpu for SRIOV.
> >
> > And driver get pm default clk also from amdgpu default clk and never
> > be changed by others. So use amdgpu default clk value for SRIOV and
> > non-dpm cases.
> 
> This won't work for vega10 or Raven since we don't parse the default clock
> info on them anymore due to atom firmware changes.

I don't get the info.
Even so, we need to support this for VI family.

> 
> Alex
> 
> >
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > index 4947f04..1935f07 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > @@ -530,8 +530,8 @@ static int amdgpu_info_ioctl(struct drm_device
> > *dev, void *data, struct drm_file
> > dev_info.max_engine_clock =
> > amdgpu_dpm_get_sclk(adev, false) * 10;
> > dev_info.max_memory_clock =
> > amdgpu_dpm_get_mclk(adev, false) * 10;
> > } else {
> > -   dev_info.max_engine_clock = adev-
> > >pm.default_sclk * 10;
> > -   dev_info.max_memory_clock = adev-
> > >pm.default_mclk * 10;
> > +   dev_info.max_engine_clock = adev-
> > >clock.default_sclk * 10;
> > +   dev_info.max_memory_clock = adev-
> > >clock.default_mclk * 10;
> > }
> > dev_info.enabled_rb_pipes_mask = adev-
> > >gfx.config.backend_enable_mask;
> > dev_info.num_rb_pipes = adev-
> > >gfx.config.max_backends_per_se *
> > --
> > 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 4/6] drm/amdgpu/psp: Do not load asd for SRIOV

2017-05-05 Thread Yu, Xiangliang

> -Original Message-
> From: Huang Rui [mailto:ray.hu...@amd.com]
> Sent: Friday, May 05, 2017 2:47 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx@lists.freedesktop.org; Wang, Daniel(Xiaowei)
> <daniel.wa...@amd.com>
> Subject: Re: [PATCH 4/6] drm/amdgpu/psp: Do not load asd for SRIOV
> 
> On Thu, May 04, 2017 at 02:36:35PM +0800, Xiangliang Yu wrote:
> > If psp version doesn't match asd version, asd loading will be failed.
> > Add workaround to bypass it for sriov.
> >
> > Signed-off-by: Daniel Wang <daniel.wa...@amd.com>
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> > index ac5e92e..5041073 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> > @@ -230,6 +230,13 @@ static int psp_asd_load(struct psp_context *psp)
> > int ret;
> > struct psp_gfx_cmd_resp *cmd;
> >
> > +   /* If PSP version doesn't match ASD version, asd loading will be failed.
> > +* add workaround to bypass it for sriov now.
> > +* TODO: add version check to make it common
> > +*/
> 
> Which psp version? Firmware or boot loader? Can you explain clear?

SRIOV doesn't care about ASD, I'll remove the comments later to avoid confusing.

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


RE: [PATCH] drm/amdgpu: Bypass GMC, UVD and VCE in hw_fini

2017-05-03 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>



Thanks!
Xiangliang Yu


> -Original Message-
> From: Trigger Huang [mailto:trigger.hu...@amd.com]
> Sent: Thursday, May 04, 2017 10:40 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>; Yu, Xiangliang
> <xiangliang...@amd.com>; Huang, Trigger <trigger.hu...@amd.com>
> Subject: [PATCH] drm/amdgpu: Bypass GMC, UVD and VCE in hw_fini
> 
> Some hw finish operations should not be applied in SR-IOV case.
> This works as workaround to fix multi-VFs reboot/shutdown issues
> 
> Signed-off-by: Trigger Huang <trigger.hu...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c |  6 ++
> drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c |  8 +++-
> drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 10 --
>  3 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> index dc1e1c1..8f1eb6f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> @@ -781,6 +781,12 @@ static int gmc_v9_0_hw_fini(void *handle)  {
>   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> 
> + if (amdgpu_sriov_vf(adev)) {
> + /* full access mode, so don't touch any GMC register */
> + DRM_INFO("For SRIOV client, shouldn't do anything.\n");
> + return 0;
> + }
> +
>   amdgpu_irq_put(adev, >mc.vm_fault, 0);
>   gmc_v9_0_gart_disable(adev);
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> index 6e9359d..2dc6127 100644
> --- a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> @@ -562,7 +562,13 @@ static int uvd_v7_0_hw_fini(void *handle)
>   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
>   struct amdgpu_ring *ring = >uvd.ring;
> 
> - uvd_v7_0_stop(adev);
> + if (!amdgpu_sriov_vf(adev))
> + uvd_v7_0_stop(adev);
> + else {
> + /* full access mode, so don't touch any UVD register */
> + DRM_INFO("For SRIOV client, shouldn't do anything.\n");
> + }
> +
>   ring->ready = false;
> 
>   return 0;
> diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> b/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> index 661f883..6dacada 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> @@ -505,8 +505,14 @@ static int vce_v4_0_hw_fini(void *handle)
>   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
>   int i;
> 
> - /* vce_v4_0_wait_for_idle(handle); */
> - vce_v4_0_stop(adev);
> + if (!amdgpu_sriov_vf(adev)) {
> + /* vce_v4_0_wait_for_idle(handle); */
> + vce_v4_0_stop(adev);
> + } else {
> + /* full access mode, so don't touch any VCE register */
> + DRM_INFO("For SRIOV client, shouldn't do anything.\n");
> + }
> +
>   for (i = 0; i < adev->vce.num_rings; i++)
>   adev->vce.ring[i].ready = false;
> 
> --
> 2.7.4

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


RE: [PATCH 3/6] drm/amdgpu:re-write sriov_reinit_early/late

2017-05-03 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, May 03, 2017 11:48 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH 3/6] drm/amdgpu:re-write sriov_reinit_early/late
> 
> 1,this way we make those routines compatible with the sequence
>   requirment for both Tonga and Vega10
> 2,ignore PSP hw init when doing TDR, because for SR-IOV device the ucode
> won't get lost after VF FLR, so no need to invoke PSP doing the ucode
> reloading again.
> 
> Signed-off-by: Monk Liu <monk@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 63
> ++
>  1 file changed, 39 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 5161c20..5573792 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1718,19 +1718,27 @@ static int amdgpu_sriov_reinit_early(struct
> amdgpu_device *adev)  {
>   int i, r;
> 
> - for (i = 0; i < adev->num_ip_blocks; i++) {
> - if (!adev->ip_blocks[i].status.valid)
> - continue;
> -
> - if (adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_COMMON ||
> - adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_GMC ||
> - adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_IH)
> - r = adev->ip_blocks[i].version->funcs->hw_init(adev);
> + static enum amd_ip_block_type ip_order[] = {
> + AMD_IP_BLOCK_TYPE_GMC,
> + AMD_IP_BLOCK_TYPE_COMMON,
> + AMD_IP_BLOCK_TYPE_GFXHUB,
> + AMD_IP_BLOCK_TYPE_MMHUB,
> + AMD_IP_BLOCK_TYPE_IH,
> + };
> +
> + for (i = 0; i < sizeof(ip_order)/sizeof(ip_order[0]); i++) {
> + int j;
> + struct amdgpu_ip_block *block;
> +
> + for (j = 0; j < adev->num_ip_blocks; j++) {
> + block = >ip_blocks[j];
> +
> + if (block->version->type != ip_order[i] ||
> + !block->status.valid)
> + continue;
> 
> - if (r) {
> - DRM_ERROR("resume of IP block <%s> failed %d\n",
> -   adev->ip_blocks[i].version->funcs->name,
> r);
> - return r;
> + r = block->version->funcs->hw_init(adev);
> + DRM_INFO("RE-INIT: %s %s\n", block->version-
> >funcs->name,
> +r?"failed":"successed");
>   }
>   }
> 
> @@ -1741,20 +1749,27 @@ static int amdgpu_sriov_reinit_late(struct
> amdgpu_device *adev)  {
>   int i, r;
> 
> - for (i = 0; i < adev->num_ip_blocks; i++) {
> - if (!adev->ip_blocks[i].status.valid)
> - continue;
> + static enum amd_ip_block_type ip_order[] = {
> + AMD_IP_BLOCK_TYPE_SMC,
> + AMD_IP_BLOCK_TYPE_DCE,
> + AMD_IP_BLOCK_TYPE_GFX,
> + AMD_IP_BLOCK_TYPE_SDMA,
> + AMD_IP_BLOCK_TYPE_VCE,
> + };
> 
> - if (adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_COMMON ||
> - adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_GMC ||
> - adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_IH )
> - continue;
> + for (i = 0; i < sizeof(ip_order)/sizeof(ip_order[0]); i++) {
> + int j;
> + struct amdgpu_ip_block *block;
> 
> - r = adev->ip_blocks[i].version->funcs->hw_init(adev);
> - if (r) {
> - DRM_ERROR("resume of IP block <%s> failed %d\n",
> -   adev->ip_blocks[i].version->funcs->name,
> r);
> - return r;
> + for (j = 0; j < adev->num_ip_blocks; j++) {
> + block = >ip_blocks[j];
> +
> + if (block->version->type != ip_order[i] ||
> + !block->status.valid)
> + continue;
> +
> + r = block->version->funcs->hw_init(adev);
> + DRM_INFO("RE-INIT: %s %s\n", block->version-
> >funcs->name,
> +r?"failed":"successed");
>   }
>   }
> 
> --
> 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 5/6] drm/amdgpu:kiq reg access need timeout(v2)

2017-05-03 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, May 03, 2017 11:48 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH 5/6] drm/amdgpu:kiq reg access need timeout(v2)
> 
> this is to prevent fence forever waiting if FLR occured during register
> accessing.
> 
> v2:
> use define instead of hardcode for the timeout msec
> 
> Change-Id: I32cc219a08f5a67654beb26c45d1b95d2b60cc96
> Signed-off-by: Monk Liu <monk@amd.com>
> Reviewed-by: Christian König <christian.koe...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index 966bf7f..757cbc4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -22,6 +22,7 @@
>   */
> 
>  #include "amdgpu.h"
> +#define MAX_KIQ_REG_WAIT 10
> 
>  int amdgpu_allocate_static_csa(struct amdgpu_device *adev)  { @@ -128,10
> +129,12 @@ uint32_t amdgpu_virt_kiq_rreg(struct amdgpu_device *adev,
> uint32_t reg)
>   amdgpu_ring_commit(ring);
>   mutex_unlock(>ring_mutex);
> 
> - r = fence_wait(f, false);
> - if (r)
> - DRM_ERROR("wait for kiq fence error: %ld.\n", r);
> + r = fence_wait_timeout(f, false,
> msecs_to_jiffies(MAX_KIQ_REG_WAIT));
>   fence_put(f);
> + if (r < 1) {
> + DRM_ERROR("wait for kiq fence error: %ld.\n", r);
> + return ~0;
> + }
> 
>   val = adev->wb.wb[adev->virt.reg_val_offs];
> 
> @@ -154,8 +157,8 @@ void amdgpu_virt_kiq_wreg(struct amdgpu_device
> *adev, uint32_t reg, uint32_t v)
>   amdgpu_ring_commit(ring);
>   mutex_unlock(>ring_mutex);
> 
> - r = fence_wait(f, false);
> - if (r)
> + r = fence_wait_timeout(f, false,
> msecs_to_jiffies(MAX_KIQ_REG_WAIT));
> + if (r < 1)
>   DRM_ERROR("wait for kiq fence error: %ld.\n", r);
>   fence_put(f);
>  }
> --
> 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 4/6] drm/amdgpu:cleanups KIQ ring_funcs emit_frame_size

2017-05-03 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, May 03, 2017 11:48 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH 4/6] drm/amdgpu:cleanups KIQ ring_funcs emit_frame_size
> 
> since we don't need hdp flush/inval for KIQ anymore
> 
> Change-Id: I8518f479afebb73c68ef922880f92dae53b665b9
> Signed-off-by: Monk Liu <monk@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 --
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 --
>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 9629f3a..022a319 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -6988,8 +6988,6 @@ static const struct amdgpu_ring_funcs
> gfx_v8_0_ring_funcs_kiq = {
>   .set_wptr = gfx_v8_0_ring_set_wptr_compute,
>   .emit_frame_size =
>   20 + /* gfx_v8_0_ring_emit_gds_switch */
> - 7 + /* gfx_v8_0_ring_emit_hdp_flush */
> - 5 + /* gfx_v8_0_ring_emit_hdp_invalidate */
>   7 + /* gfx_v8_0_ring_emit_pipeline_sync */
>   17 + /* gfx_v8_0_ring_emit_vm_flush */
>   7 + 7 + 7, /* gfx_v8_0_ring_emit_fence_kiq x3 for user fence,
> vm fence */ diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 2b2a2c2..6d5b66c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -3620,8 +3620,6 @@ static const struct amdgpu_ring_funcs
> gfx_v9_0_ring_funcs_kiq = {
>   .set_wptr = gfx_v9_0_ring_set_wptr_compute,
>   .emit_frame_size =
>   20 + /* gfx_v9_0_ring_emit_gds_switch */
> - 7 + /* gfx_v9_0_ring_emit_hdp_flush */
> - 5 + /* gfx_v9_0_ring_emit_hdp_invalidate */
>   7 + /* gfx_v9_0_ring_emit_pipeline_sync */
>   24 + /* gfx_v9_0_ring_emit_vm_flush */
>   8 + 8 + 8, /* gfx_v9_0_ring_emit_fence_kiq x3 for user fence,
> vm fence */
> --
> 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 2/6] drm/amdgpu:need som change on vega10 mailbox

2017-05-03 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, May 03, 2017 11:48 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH 2/6] drm/amdgpu:need som change on vega10 mailbox
> 
> if sriov gpu reset is invoked by job timeout, it is run in a global work-queue
> which is very slow and better not call msleep ortherwise it takes long time to
> get back CPU.
> 
> so make below changes:
> 
> 1: Change msleep 1 to mdelay 5
> 2: Ignore the ack fail from pf after time out,
>because VF FLR will clear ack, sometime VF FLR is done
>prior to the beginning of poll_ack so we can ignore this ack
> 
> TODO:
> Put job_timedout (and the following gpu reset) in a driver thread, instead of
> the global work_struct.
> 
> Change-Id: I4608c67b55c67c88597e03eee35a126d7e850839
> Signed-off-by: Monk Liu <monk@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 18 ++
> drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 10 +-
>  2 files changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
> index 712f36e..e967a7b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
> @@ -124,8 +124,8 @@ static int xgpu_ai_poll_ack(struct amdgpu_device
> *adev)
>   r = -ETIME;
>   break;
>   }
> - msleep(1);
> - timeout -= 1;
> + mdelay(5);
> + timeout -= 5;
> 
>   reg = RREG32_NO_KIQ(SOC15_REG_OFFSET(NBIO, 0,
> 
> mmBIF_BX_PF0_MAILBOX_CONTROL)); @@ -141,12 +141,12 @@ static int
> xgpu_ai_poll_msg(struct amdgpu_device *adev, enum idh_event event)
>   r = xgpu_ai_mailbox_rcv_msg(adev, event);
>   while (r) {
>   if (timeout <= 0) {
> - pr_err("Doesn't get ack from pf.\n");
> + pr_err("Doesn't get msg:%d from pf.\n", event);
>   r = -ETIME;
>   break;
>   }
> - msleep(1);
> - timeout -= 1;
> + mdelay(5);
> + timeout -= 5;
> 
>   r = xgpu_ai_mailbox_rcv_msg(adev, event);
>   }
> @@ -165,7 +165,7 @@ static int xgpu_ai_send_access_requests(struct
> amdgpu_device *adev,
>   /* start to poll ack */
>   r = xgpu_ai_poll_ack(adev);
>   if (r)
> - return r;
> + pr_err("Doesn't get ack from pf, continue\n");
> 
>   xgpu_ai_mailbox_set_valid(adev, false);
> 
> @@ -174,8 +174,10 @@ static int xgpu_ai_send_access_requests(struct
> amdgpu_device *adev,
>   req == IDH_REQ_GPU_FINI_ACCESS ||
>   req == IDH_REQ_GPU_RESET_ACCESS) {
>   r = xgpu_ai_poll_msg(adev, IDH_READY_TO_ACCESS_GPU);
> - if (r)
> + if (r) {
> + pr_err("Doesn't get READY_TO_ACCESS_GPU from
> pf, give up\n");
>   return r;
> + }
>   }
> 
>   return 0;
> @@ -211,7 +213,7 @@ static int xgpu_ai_mailbox_ack_irq(struct
> amdgpu_device *adev,
>   struct amdgpu_irq_src *source,
>   struct amdgpu_iv_entry *entry)
>  {
> - DRM_DEBUG("get ack intr and do nothing.\n");
> + printk("get ack intr and do nothing.\n");
>   return 0;
>  }
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index 7bdc51b..f0d64f1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -398,8 +398,8 @@ static int xgpu_vi_poll_ack(struct amdgpu_device
> *adev)
>   r = -ETIME;
>   break;
>   }
> - msleep(1);
> - timeout -= 1;
> + mdelay(5);
> + timeout -= 5;
> 
>   reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
>   }
> @@ -418,8 +418,8 @@ static int xgpu_vi_poll_msg(struct amdgpu_device
> *adev, enum idh_event event)
>   r = -ETIME;
>   break;
>   }
> - msleep(1);
> - timeout -= 1;
> + mdelay(5);
> + timeout -= 5;
> 
>   r = xgpu_vi_mailbox_rcv_msg(adev, event);
>   }
> @@ -44

RE: [PATCH] drm/amdgpu: Enable chained IB MCBP support

2017-04-27 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


Thanks!
Xiangliang Yu

> -Original Message-
> From: Trigger Huang [mailto:trigger.hu...@amd.com]
> Sent: Thursday, April 27, 2017 3:18 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>; Yu, Xiangliang
> <xiangliang...@amd.com>; Huang, Trigger <trigger.hu...@amd.com>
> Subject: [PATCH] drm/amdgpu: Enable chained IB MCBP support
> 
> Support for MCBP/Virtualization in combination with chained IBs is formal
> released on firmware feature version #46. So enable it according to firmware
> feature version, otherwise, world switch will hang.
> 
> Signed-off-by: Trigger Huang <trigger.hu...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 2ff5f19..9a8c042 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -941,12 +941,6 @@ static int gfx_v8_0_init_microcode(struct
> amdgpu_device *adev)
>   cp_hdr = (const struct gfx_firmware_header_v1_0 *)adev-
> >gfx.me_fw->data;
>   adev->gfx.me_fw_version = le32_to_cpu(cp_hdr-
> >header.ucode_version);
> 
> - /* chain ib ucode isn't formal released, just disable it by far
> -  * TODO: when ucod ready we should use ucode version to judge if
> -  * chain-ib support or not.
> -  */
> - adev->virt.chained_ib_support = false;
> -
>   adev->gfx.me_feature_version = le32_to_cpu(cp_hdr-
> >ucode_feature_version);
> 
>   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ce.bin",
> chip_name); @@ -960,6 +954,17 @@ static int
> gfx_v8_0_init_microcode(struct amdgpu_device *adev)
>   adev->gfx.ce_fw_version = le32_to_cpu(cp_hdr-
> >header.ucode_version);
>   adev->gfx.ce_feature_version = le32_to_cpu(cp_hdr-
> >ucode_feature_version);
> 
> + /*
> +  * Support for MCBP/Virtualization in combination with chained IBs is
> +  * formal released on feature version #46
> +  */
> + if (adev->gfx.ce_feature_version >= 46 &&
> + adev->gfx.pfp_feature_version >= 46) {
> + adev->virt.chained_ib_support = true;
> + DRM_INFO("Chained IB support enabled!\n");
> + } else
> + adev->virt.chained_ib_support = false;
> +
>   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin",
> chip_name);
>   err = request_firmware(>gfx.rlc_fw, fw_name, adev->dev);
>   if (err)
> --
> 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 module unload hang by KIQ on Vega10

2017-04-17 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Trigger Huang
> Sent: Tuesday, April 18, 2017 10:14 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Huang, Trigger <trigger.hu...@amd.com>
> Subject: [PATCH] drm/amdgpu: Fix module unload hang by KIQ on Vega10
> 
> Apply commit 4e683cb2644f ("drm/amdgpu: Fix module unload hang by KIQ
> IRQ set")to vega10
> 
> Signed-off-by: Trigger Huang <trigger.hu...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index f6b2329..b7b2ed8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -631,7 +631,6 @@ static int gfx_v9_0_kiq_init_ring(struct
> amdgpu_device *adev,
>   ring->pipe = 1;
>   }
> 
> - irq->data = ring;
>   ring->queue = 0;
>   ring->eop_gpu_addr = kiq->eop_gpu_addr;
>   sprintf(ring->name, "kiq %d.%d.%d", ring->me, ring->pipe, ring-
> >queue); @@ -647,7 +646,6 @@ static void gfx_v9_0_kiq_free_ring(struct
> amdgpu_ring *ring,  {
>   amdgpu_wb_free(ring->adev, ring->adev->virt.reg_val_offs);
>   amdgpu_ring_fini(ring);
> - irq->data = NULL;
>  }
> 
>  /* create MQD for each compute queue */ @@ -3367,9 +3365,9 @@ static
> int gfx_v9_0_kiq_set_interrupt_state(struct amdgpu_device *adev,
>   enum amdgpu_interrupt_state
> state)  {
>   uint32_t tmp, target;
> - struct amdgpu_ring *ring = (struct amdgpu_ring *)src->data;
> + struct amdgpu_ring *ring = &(adev->gfx.kiq.ring);
> 
> - BUG_ON(!ring || (ring->funcs->type != AMDGPU_RING_TYPE_KIQ));
> + BUG_ON(ring->funcs->type != AMDGPU_RING_TYPE_KIQ);
> 
>   if (ring->me == 1)
>   target = SOC15_REG_OFFSET(GC, 0,
> mmCP_ME1_PIPE0_INT_CNTL); @@ -3413,9 +3411,9 @@ static int
> gfx_v9_0_kiq_irq(struct amdgpu_device *adev,
>   struct amdgpu_iv_entry *entry)
>  {
>   u8 me_id, pipe_id, queue_id;
> - struct amdgpu_ring *ring = (struct amdgpu_ring *)source->data;
> + struct amdgpu_ring *ring = &(adev->gfx.kiq.ring);
> 
> - BUG_ON(!ring || (ring->funcs->type != AMDGPU_RING_TYPE_KIQ));
> + BUG_ON(ring->funcs->type != AMDGPU_RING_TYPE_KIQ);
> 
>   me_id = (entry->ring_id & 0x0c) >> 2;
>   pipe_id = (entry->ring_id & 0x03) >> 0;
> --
> 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: Destroy psp ring in hw_fini

2017-04-17 Thread Yu, Xiangliang
Better to add SRIOV case in your commit message, I think bare metal doesn't 
care re-initialization.
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com> with fixing.


Thanks!
Xiangliang Yu


> -Original Message-
> From: Trigger Huang [mailto:trigger.hu...@amd.com]
> Sent: Tuesday, April 18, 2017 10:26 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>; Yu, Xiangliang
> <xiangliang...@amd.com>; Huang, Ray <ray.hu...@amd.com>; Huang,
> Trigger <trigger.hu...@amd.com>
> Subject: [PATCH] drm/amdgpu: Destroy psp ring in hw_fini
> 
> Fix issue that PSP initialization will fail if reload amdgpu module.
> That's because the PSP ring must be destroyed to be ready for the next time
> PSP initialization.
> 
> Signed-off-by: Trigger Huang <trigger.hu...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c |  3 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h |  3 +++
>  drivers/gpu/drm/amd/amdgpu/psp_v3_1.c   | 27
> +++
>  drivers/gpu/drm/amd/amdgpu/psp_v3_1.h   |  2 ++
>  4 files changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index 19180aa..51b8a15 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -56,6 +56,7 @@ static int psp_sw_init(void *handle)
>   psp->prep_cmd_buf = psp_v3_1_prep_cmd_buf;
>   psp->ring_init = psp_v3_1_ring_init;
>   psp->ring_create = psp_v3_1_ring_create;
> + psp->ring_destroy = psp_v3_1_ring_destroy;
>   psp->cmd_submit = psp_v3_1_cmd_submit;
>   psp->compare_sram_data = psp_v3_1_compare_sram_data;
>   psp->smu_reload_quirk = psp_v3_1_smu_reload_quirk; @@
> -425,6 +426,8 @@ static int psp_hw_fini(void *handle)
>   amdgpu_bo_free_kernel(>fence_buf_bo,
> >fence_buf_mc_addr, 
> >fence_buf);
> 
> + psp_ring_destroy(psp, PSP_RING_TYPE__KM);
> +
>   return 0;
>  }
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
> index 28faba5..0301e4e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
> @@ -66,6 +66,8 @@ struct psp_context
>   struct psp_gfx_cmd_resp *cmd);
>   int (*ring_init)(struct psp_context *psp, enum psp_ring_type
> ring_type);
>   int (*ring_create)(struct psp_context *psp, enum psp_ring_type
> ring_type);
> + int (*ring_destroy)(struct psp_context *psp,
> + enum psp_ring_type ring_type);
>   int (*cmd_submit)(struct psp_context *psp, struct
> amdgpu_firmware_info *ucode,
> uint64_t cmd_buf_mc_addr, uint64_t
> fence_mc_addr, int index);
>   bool (*compare_sram_data)(struct psp_context *psp, @@ -116,6
> +118,7 @@ struct amdgpu_psp_funcs {  #define psp_prep_cmd_buf(ucode,
> type) (psp)->prep_cmd_buf((ucode), (type))  #define psp_ring_init(psp,
> type) (psp)->ring_init((psp), (type))  #define psp_ring_create(psp, type)
> (psp)->ring_create((psp), (type))
> +#define psp_ring_destroy(psp, type) ((psp)->ring_destroy((psp),
> +(type)))
>  #define psp_cmd_submit(psp, ucode, cmd_mc, fence_mc, index) \
>   (psp)->cmd_submit((psp), (ucode), (cmd_mc), (fence_mc),
> (index))  #define psp_compare_sram_data(psp, ucode, type) \ diff --git
> a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
> b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
> index d351583..e834b55 100644
> --- a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
> @@ -321,6 +321,33 @@ int psp_v3_1_ring_create(struct psp_context *psp,
> enum psp_ring_type ring_type)
>   return ret;
>  }
> 
> +int psp_v3_1_ring_destroy(struct psp_context *psp, enum psp_ring_type
> +ring_type) {
> + int ret = 0;
> + struct psp_ring *ring;
> + unsigned int psp_ring_reg = 0;
> + struct amdgpu_device *adev = psp->adev;
> +
> + ring = >km_ring;
> +
> + /* Write the ring destroy command to C2PMSG_64 */
> + psp_ring_reg = 3 << 16;
> + WREG32(SOC15_REG_OFFSET(MP0, 0, mmMP0_SMN_C2PMSG_64),
> psp_ring_reg);
> +
> + /* there might be handshake issue with hardware which needs delay
> */
> + mdelay(20);
> +
> + /* Wait for response flag (bit 31) in C2PMSG_64 */
> + ret = psp_wait_for(psp, SOC15_REG_OFFSET(MP0, 0,
> mmMP0_SMN_C2PMSG_64),
> +0x8000, 0x8000, false);
> +
> + if (ring->ring_mem)
> + amdgpu_bo_free_k

RE: [PATCH] drm/amdgpu: set kiq irq in sriov case for gfx_v9.

2017-04-17 Thread Yu, Xiangliang
Please refer to commit 4e683cb26 that fix for gfx8, I think the commit can also 
fix BUG_ON case of gfx9.

Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Monday, April 17, 2017 8:31 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex 
> Subject: [PATCH] drm/amdgpu: set kiq irq in sriov case for gfx_v9.
> 
> As the kiq ring is NULL in baremetal case, the irq function will result in a
> BUG_ON in some case.
> 
> Signed-off-by: Rex Zhu 
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index f6b2329..35657c3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -1029,9 +1029,11 @@ static int gfx_v9_0_sw_init(void *handle)
>   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> 
>   /* KIQ event */
> - r = amdgpu_irq_add_id(adev, AMDGPU_IH_CLIENTID_GRBM_CP,
> 178, >gfx.kiq.irq);
> - if (r)
> - return r;
> + if (amdgpu_sriov_vf()) {
> + r = amdgpu_irq_add_id(adev,
> AMDGPU_IH_CLIENTID_GRBM_CP, 178, >gfx.kiq.irq);
> + if (r)
> + return r;
> + }
> 
>   /* EOP Event */
>   r = amdgpu_irq_add_id(adev, AMDGPU_IH_CLIENTID_GRBM_CP,
> 181, >gfx.eop_irq); @@ -3590,9 +3592,10 @@ static void
> gfx_v9_0_set_irq_funcs(struct amdgpu_device *adev)
> 
>   adev->gfx.priv_inst_irq.num_types = 1;
>   adev->gfx.priv_inst_irq.funcs = _v9_0_priv_inst_irq_funcs;
> -
> - adev->gfx.kiq.irq.num_types = AMDGPU_CP_KIQ_IRQ_LAST;
> - adev->gfx.kiq.irq.funcs = _v9_0_kiq_irq_funcs;
> + if (amdgpu_sriov_vf(adev)) {
> + adev->gfx.kiq.irq.num_types = AMDGPU_CP_KIQ_IRQ_LAST;
> + adev->gfx.kiq.irq.funcs = _v9_0_kiq_irq_funcs;
> + }
>  }
> 
>  static void gfx_v9_0_set_rlc_funcs(struct amdgpu_device *adev)
> --
> 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 2/3] drm/amdgpu/vce4: workaround VCE ring test slow issue

2017-04-11 Thread Yu, Xiangliang
> > -Original Message-
> > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Xiangliang Yu
> > Sent: Tuesday, April 11, 2017 3:31 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Min, Frank; Yu, Xiangliang
> > Subject: [PATCH 2/3] drm/amdgpu/vce4: workaround VCE ring test slow
> > issue
> >
> > Add VCE ring test slow workaround for SRIOV.
> >
> > Signed-off-by: Frank Min <frank@amd.com>
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> > index e43c83f..cdff938 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> > @@ -955,7 +955,11 @@ int amdgpu_vce_ring_test_ring(struct
> amdgpu_ring
> > *ring)
> > struct amdgpu_device *adev = ring->adev;
> > uint32_t rptr = amdgpu_ring_get_rptr(ring);
> > unsigned i;
> > -   int r;
> > +   int r, timeout = adev->usec_timeout;
> 
> Do you need longer timeouts elsewhere as well?  If so, it might make more
> sense to just change the default setting for adev->usec_timeout for SR-IOV.

No, just this case for temporarily.

> 
> > +
> > +   /* workaround VCE ring test slow issue for sriov*/
> > +   if (amdgpu_sriov_vf(adev))
> > +   timeout *= 10;
> >
> > /* TODO: remove it if VCE can work for sriov */
> > if (amdgpu_sriov_vf(adev))
> > @@ -970,13 +974,13 @@ int amdgpu_vce_ring_test_ring(struct
> amdgpu_ring
> > *ring)
> > amdgpu_ring_write(ring, VCE_CMD_END);
> > amdgpu_ring_commit(ring);
> >
> > -   for (i = 0; i < adev->usec_timeout; i++) {
> > +   for (i = 0; i < timeout; i++) {
> > if (amdgpu_ring_get_rptr(ring) != rptr)
> > break;
> > DRM_UDELAY(1);
> > }
> >
> > -   if (i < adev->usec_timeout) {
> > +   if (i < timeout) {
> > DRM_INFO("ring test on %d succeeded in %d usecs\n",
> >  ring->idx, i);
> > } else {
> > --
> > 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 firmware UCODE_ID_STORAGE issue

2017-04-10 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Trigger Huang
> Sent: Monday, April 10, 2017 2:46 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Huang, Ray <ray.hu...@amd.com>; Huang, Trigger
> <trigger.hu...@amd.com>
> Subject: [PATCH] drm/amdgpu: Fix firmware UCODE_ID_STORAGE issue
> 
> In Tonga's virtualization environment, for firmware UCODE_ID_STORAGE,
> there is no actual firmware data, but we still need alloc a BO and tell the 
> BO's
> mc address to HW, or world switch will hang on VFs.
> 
> Signed-off-by: Trigger Huang <trigger.hu...@amd.com>
> ---
>  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 a1891c9..b7307b0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> @@ -383,7 +383,7 @@ int amdgpu_ucode_init_bo(struct amdgpu_device
> *adev)
>* ucode info here
>*/
>   if (adev->firmware.load_type != AMDGPU_FW_LOAD_PSP)
> - adev->firmware.max_ucodes =
> AMDGPU_UCODE_ID_MAXIMUM - 4;
> + adev->firmware.max_ucodes =
> AMDGPU_UCODE_ID_MAXIMUM - 3;
>   else
>   adev->firmware.max_ucodes =
> AMDGPU_UCODE_ID_MAXIMUM;
> 
> --
> 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 3/5] drm/amdgpu/vce4: workaround multi vce engine encoding hang issue

2017-04-10 Thread Yu, Xiangliang
> Am 09.04.2017 um 14:31 schrieb Xiangliang Yu:
> > For SRIOV, multi vce engine will hang when encoding. Add VMHUB flush
> > to workaround it, will continue to find the root cause later.
> 
> NAK, that won't work and can cause hangs as well.
> 
> The hang you experience could be a known issue with old libdrm, do you
> have updated to the latest version?

Ok, I'll try it later.

> 
> >
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > Signed-off-by: Frank Min <frank@amd.com>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 11 +++
> >   1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> > b/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> > index d3448d0..b4e36f3 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> > @@ -31,6 +31,7 @@
> >   #include "soc15d.h"
> >   #include "soc15_common.h"
> >   #include "mmsch_v1_0.h"
> > +#include "gmc_v9_0.h"
> >
> >   #include "vega10/soc15ip.h"
> >   #include "vega10/VCE/vce_4_0_offset.h"
> > @@ -971,6 +972,7 @@ static void vce_v4_0_emit_vm_flush(struct
> amdgpu_ring *ring,
> > uint32_t req = ring->adev->gart.gart_funcs-
> >get_invalidate_req(vm_id);
> > unsigned eng = ring->idx;
> > unsigned i;
> > +   struct amdgpu_device *adev = ring->adev;
> >
> > pd_addr = pd_addr | 0x1; /* valid bit */
> > /* now only use physical base address of PDE and valid */ @@ -979,6
> > +981,15 @@ static void vce_v4_0_emit_vm_flush(struct amdgpu_ring
> *ring,
> > for (i = 0; i < AMDGPU_MAX_VMHUBS; ++i) {
> > struct amdgpu_vmhub *hub = >adev->vmhub[i];
> >
> > +   /* Workaround multi vce engine encoding hang issue */
> > +   if (i && amdgpu_sriov_vf(adev)) {
> > +   WREG32_NO_KIQ(hub->ctx0_ptb_addr_lo32 +
> vm_id * 2,
> > + lower_32_bits(pd_addr));
> > +   WREG32_NO_KIQ(hub->ctx0_ptb_addr_hi32 +
> vm_id * 2,
> > + upper_32_bits(pd_addr));
> > +   gmc_v9_0_flush_vmhub(adev, hub, eng, vm_id);
> > +   }
> > +
> > amdgpu_ring_write(ring, VCE_CMD_REG_WRITE);
> > amdgpu_ring_write(ring,
> > (hub->ctx0_ptb_addr_hi32 + vm_id * 2) << 2);
> 

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


RE: [PATCH 1/6] drm/amdgpu:add PSP block only load_type=PSP

2017-04-05 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com> for the series.


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, April 05, 2017 5:11 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH 1/6] drm/amdgpu:add PSP block only load_type=PSP
> 
> SRIOV currently only can load ucode directly, and PSP block is not supported
> by VF temporarily.
> 
> will remove this restrict and use PSP load all ucode even for SRIOV later
> 
> Change-Id: I6df5c4088c7c72d01928d5af8bfe5520447619ba
> Signed-off-by: Monk Liu <monk@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/soc15.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
> b/drivers/gpu/drm/amd/amdgpu/soc15.c
> index 06afbcc..2955c0c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/soc15.c
> +++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
> @@ -497,7 +497,8 @@ int soc15_set_ip_blocks(struct amdgpu_device *adev)
>   amdgpu_ip_block_add(adev, _v1_0_ip_block);
>   amdgpu_ip_block_add(adev, _v9_0_ip_block);
>   amdgpu_ip_block_add(adev, _ih_ip_block);
> - amdgpu_ip_block_add(adev, _v3_1_ip_block);
> + if (adev->firmware.load_type == AMDGPU_FW_LOAD_PSP)
> + amdgpu_ip_block_add(adev, _v3_1_ip_block);
>   if (!amdgpu_sriov_vf(adev))
>   amdgpu_ip_block_add(adev,
> _pp_ip_block);
>   if (adev->enable_virtual_display || amdgpu_sriov_vf(adev))
> --
> 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/virt: fix spelling mistake: "hypervior" -> "hypervisor"

2017-03-30 Thread Yu, Xiangliang
> 
> From: Colin Ian King <colin.k...@canonical.com>
> 
> trivial fix to spelling mistake in DRM_ERROR error message
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index d2622b6f49fa..94af75fc6321 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -487,7 +487,7 @@ static void xgpu_vi_mailbox_flr_work(struct
> work_struct *work)
> 
>   r = xgpu_vi_poll_msg(adev, IDH_FLR_NOTIFICATION_CMPL);
>   if (r)
> - DRM_ERROR("failed to get flr cmpl msg from hypervior.\n");
> + DRM_ERROR("failed to get flr cmpl msg from hypervisor.\n");
> 


Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH 00/13] *** VEGA10 SRIOV PATCHES ***

2017-03-24 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com> for the series.


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Friday, March 24, 2017 6:38 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH 00/13] *** VEGA10 SRIOV PATCHES ***
> 
> patch 1 is a fix for VI
> patch 2 to patch 11 are bug fixings for vega10 for SRIOV patch 12/13 is the
> DMAframe scheme change to fix CE VM fault after world switch.
> 
> 
> Monk Liu (13):
>   drm/amdgpu:imple cond_exec for gfx8
>   drm/amdgpu:enable mcbp for gfx9
>   drm/amdgpu:add KIQ interrupt id
>   drm/amdgpu:virt_init_setting invoke is missed!
>   drm/amdgpu:fix ring init sequence
>   drm/amdgpu:change sequence of SDMA v4 init
>   drm/amdgpu:two fixings for sdma v4 for SRIOV
>   drm/amdgpu:no cg for soc15 of SRIOV
>   drm/amdgpu:fix gmc_v9 vm fault process for SRIOV
>   drm/amdgpu:fix ring_write_multiple
>   drm/amdgpu:fix missing programing critical registers
>   drm/amdgpu:changes in gfx DMAframe scheme
>   drm/amdgpu:change emit_frame_size of gfx8
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   |  8 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c |  6 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   | 77
> +++-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 57 ++
> -
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 37 ++-
>  drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c |  9 
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 28 
>  drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c  |  9 
>  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   | 43 +-
>  drivers/gpu/drm/amd/amdgpu/soc15.c   |  7 +++
>  12 files changed, 206 insertions(+), 81 deletions(-)
> 
> --
> 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 1/9] drm/amdgpu/gfx9: Switch baremetal to use KIQ for compute ring management. (v2)

2017-03-23 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com> for the whole series.


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Alex Deucher
> Sent: Friday, March 24, 2017 1:07 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander <alexander.deuc...@amd.com>
> Subject: [PATCH 1/9] drm/amdgpu/gfx9: Switch baremetal to use KIQ for
> compute ring management. (v2)
> 
> KIQ is the Kernel Interface Queue for managing the MEC.  Rather than setting
> up rings via direct MMIO of ring registers, the rings are configured via 
> special
> packets sent to the KIQ.  The allows the MEC to better manage shared
> resources and certain power events. It also reduces the code paths in the
> driver to support and is required for MEC powergating.
> 
> v2: drop gfx_v9_0_cp_compute_fini() as well
> 
> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 321 +++
> ---
>  1 file changed, 24 insertions(+), 297 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index ad82ab7..09a3710 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -1094,23 +1094,21 @@ static int gfx_v9_0_sw_init(void *handle)
>   return r;
>   }
> 
> - if (amdgpu_sriov_vf(adev)) {
> - r = gfx_v9_0_kiq_init(adev);
> - if (r) {
> - DRM_ERROR("Failed to init KIQ BOs!\n");
> - return r;
> - }
> + r = gfx_v9_0_kiq_init(adev);
> + if (r) {
> + DRM_ERROR("Failed to init KIQ BOs!\n");
> + return r;
> + }
> 
> - kiq = >gfx.kiq;
> - r = gfx_v9_0_kiq_init_ring(adev, >ring, >irq);
> - if (r)
> - return r;
> + kiq = >gfx.kiq;
> + r = gfx_v9_0_kiq_init_ring(adev, >ring, >irq);
> + if (r)
> + return r;
> 
> - /* create MQD for all compute queues as wel as KIQ for
> SRIOV case */
> - r = gfx_v9_0_compute_mqd_soft_init(adev);
> - if (r)
> - return r;
> - }
> + /* create MQD for all compute queues as wel as KIQ for SRIOV case
> */
> + r = gfx_v9_0_compute_mqd_soft_init(adev);
> + if (r)
> + return r;
> 
>   /* reserve GDS, GWS and OA resource for gfx */
>   r = amdgpu_bo_create_kernel(adev, adev-
> >gds.mem.gfx_partition_size, @@ -1157,11 +1155,9 @@ static int
> gfx_v9_0_sw_fini(void *handle)
>   for (i = 0; i < adev->gfx.num_compute_rings; i++)
>   amdgpu_ring_fini(>gfx.compute_ring[i]);
> 
> - if (amdgpu_sriov_vf(adev)) {
> - gfx_v9_0_compute_mqd_soft_fini(adev);
> - gfx_v9_0_kiq_free_ring(>gfx.kiq.ring, 
> >gfx.kiq.irq);
> - gfx_v9_0_kiq_fini(adev);
> - }
> + gfx_v9_0_compute_mqd_soft_fini(adev);
> + gfx_v9_0_kiq_free_ring(>gfx.kiq.ring, >gfx.kiq.irq);
> + gfx_v9_0_kiq_fini(adev);
> 
>   gfx_v9_0_mec_fini(adev);
>   gfx_v9_0_ngg_fini(adev);
> @@ -1732,13 +1728,6 @@ static void gfx_v9_0_cp_compute_enable(struct
> amdgpu_device *adev, bool enable)
>   udelay(50);
>  }
> 
> -static int gfx_v9_0_cp_compute_start(struct amdgpu_device *adev) -{
> - gfx_v9_0_cp_compute_enable(adev, true);
> -
> - return 0;
> -}
> -
>  static int gfx_v9_0_cp_compute_load_microcode(struct amdgpu_device
> *adev)  {
>   const struct gfx_firmware_header_v1_0 *mec_hdr; @@ -1781,45
> +1770,6 @@ static int gfx_v9_0_cp_compute_load_microcode(struct
> amdgpu_device *adev)
>   return 0;
>  }
> 
> -static void gfx_v9_0_cp_compute_fini(struct amdgpu_device *adev) -{
> - int i, r;
> -
> - for (i = 0; i < adev->gfx.num_compute_rings; i++) {
> - struct amdgpu_ring *ring = >gfx.compute_ring[i];
> -
> - if (ring->mqd_obj) {
> - r = amdgpu_bo_reserve(ring->mqd_obj, false);
> - if (unlikely(r != 0))
> - dev_warn(adev->dev, "(%d) reserve MQD
> bo failed\n", r);
> -
> - amdgpu_bo_unpin(ring->mqd_obj);
> - amdgpu_bo_unreserve(ring->mqd_obj);
> -
> - amdgpu_bo_unref(>mqd_obj);
> - ring->mqd_obj = NULL;
> - }
> - }
> -}
> -
> -static int gfx_v9_0_init_queue(struct amdgpu_ring *ring);
>

RE: [PATCH] drm/amdgpu/virt: don't check VALID bit for FLR completion message

2017-02-23 Thread Yu, Xiangliang

Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Thursday, February 23, 2017 3:09 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Ding, Pixel <pixel.d...@amd.com>
> Subject: [PATCH] drm/amdgpu/virt: don't check VALID bit for FLR completion
> message
> 
> The interrupt after FLR is missed sometimes due to hardware reason, so
> guest driver get the notification of FLR completion via polling message. Then
> host doesn't write VALID bit to avoid sending interrupt, otherwise the
> completion will be handled twice.
> 
> So there's a valid message without VALID bit for FLR completion, driver
> should handle it without checking.
> 
> Signed-off-by: Pixel Ding <pixel.d...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index 3164d61..3c6b0af 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -368,9 +368,12 @@ static int xgpu_vi_mailbox_rcv_msg(struct
> amdgpu_device *adev,
>   u32 reg;
>   u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> 
> - reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
> - if (!(reg & mask))
> - return -ENOENT;
> + /* workaround: host driver doesn't set VALID for CMPL now */
> + if (event != IDH_FLR_NOTIFICATION_CMPL) {
> + reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
> + if (!(reg & mask))
> + return -ENOENT;
> + }
> 
>   reg = RREG32_NO_KIQ(mmMAILBOX_MSGBUF_RCV_DW0);
>   if (reg != event)
> --
> 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/virt: don't check VALID bit for FLR completion message

2017-02-22 Thread Yu, Xiangliang
> The interrupt after FLR is missed sometimes due to hardware reason, so
> guest driver get the notification of FLR completion via polling message. Then
> host doesn't write VALID bit to avoid sending interrupt, otherwise the
> completion will be handled twice.
> 
> So there's a valid message without VALID bit for FLR completion, driver
> should handle it without checking.
> 
> Signed-off-by: Pixel Ding 
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index 3164d61..285d54c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -369,7 +369,7 @@ static int xgpu_vi_mailbox_rcv_msg(struct
> amdgpu_device *adev,
>   u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> 
>   reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
> - if (!(reg & mask))
> + if (!(reg & mask) && (event != IDH_FLR_NOTIFICATION_CMPL))
>   return -ENOENT;

Small nitpick: better to move event check to top and add a comment. 

>   reg = RREG32_NO_KIQ(mmMAILBOX_MSGBUF_RCV_DW0);
> --
> 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 V2] drm/amdgpu: Fix module unload hang by KIQ IRQ set

2017-02-19 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu < xiangliang...@amd.com>

Thanks!
Xiangliang Yu

> -Original Message-
> From: Trigger Huang [mailto:trigger.hu...@amd.com]
> Sent: Monday, February 20, 2017 11:03 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>; Yu, Xiangliang
> <xiangliang...@amd.com>; Huang, Trigger <trigger.hu...@amd.com>
> Subject: [PATCH V2] drm/amdgpu: Fix module unload hang by KIQ IRQ set
> 
> In some cases, manually insmod/rmmod amdgpu is necessary. When
> unloading amdgpu, the KIQ IRQ enable/disable function will case system
> hang. The root cause is, in the sequence of function amdgpu_fini, the sw_fini
> of IP block AMD_IP_BLOCK_TYPE_GFX will be invoked earlier than that of
> AMD_IP_BLOCK_TYPE_IH. So continue to use the variable freed by
> AMD_IP_BLOCK_TYPE_GFX will cause system hang.
> 
> Changes in v2:
> -- Refine according to Xiangliang Yu's suggestions
> 
> Signed-off-by: Trigger Huang <trigger.hu...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 5a484ef..c417324 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -1395,7 +1395,6 @@ static int gfx_v8_0_kiq_init_ring(struct
> amdgpu_device *adev,
>   ring->pipe = 1;
>   }
> 
> - irq->data = ring;
>   ring->queue = 0;
>   sprintf(ring->name, "kiq %d.%d.%d", ring->me, ring->pipe, ring-
> >queue);
>   r = amdgpu_ring_init(adev, ring, 1024, @@ -1410,7 +1409,6 @@ static
> void gfx_v8_0_kiq_free_ring(struct amdgpu_ring *ring,  {
>   amdgpu_wb_free(ring->adev, ring->adev->virt.reg_val_offs);
>   amdgpu_ring_fini(ring);
> - irq->data = NULL;
>  }
> 
>  #define MEC_HPD_SIZE 2048
> @@ -6931,9 +6929,9 @@ static int gfx_v8_0_kiq_set_interrupt_state(struct
> amdgpu_device *adev,
>   enum amdgpu_interrupt_state
> state)  {
>   uint32_t tmp, target;
> - struct amdgpu_ring *ring = (struct amdgpu_ring *)src->data;
> + struct amdgpu_ring *ring = &(adev->gfx.kiq.ring);
> 
> - BUG_ON(!ring || (ring->funcs->type != AMDGPU_RING_TYPE_KIQ));
> + BUG_ON(ring->funcs->type != AMDGPU_RING_TYPE_KIQ);
> 
>   if (ring->me == 1)
>   target = mmCP_ME1_PIPE0_INT_CNTL;
> @@ -6977,9 +6975,9 @@ static int gfx_v8_0_kiq_irq(struct amdgpu_device
> *adev,
>   struct amdgpu_iv_entry *entry)
>  {
>   u8 me_id, pipe_id, queue_id;
> - struct amdgpu_ring *ring = (struct amdgpu_ring *)source->data;
> + struct amdgpu_ring *ring = &(adev->gfx.kiq.ring);
> 
> - BUG_ON(!ring || (ring->funcs->type != AMDGPU_RING_TYPE_KIQ));
> + BUG_ON(ring->funcs->type != AMDGPU_RING_TYPE_KIQ);
> 
>   me_id = (entry->ring_id & 0x0c) >> 2;
>   pipe_id = (entry->ring_id & 0x03) >> 0;
> --
> 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 module unload hang by KIQ IRQ set

2017-02-16 Thread Yu, Xiangliang
Hi Trigger,

Can you try to move src->data= NULL into gfx_v8_0_kiq_set_interrupt_state 
function? I think it is more simple and clear.

Thanks!
Xiangliang Yu

> -Original Message-
> From: Trigger Huang [mailto:trigger.hu...@amd.com]
> Sent: Thursday, February 16, 2017 6:48 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>; Yu, Xiangliang
> <xiangliang...@amd.com>; Huang, Trigger <trigger.hu...@amd.com>
> Subject: [PATCH] drm/amdgpu: Fix module unload hang by KIQ IRQ set
> 
> In some cases, manually insmod/rmmod amdgpu is necessary. When
> unloading amdgpu, the KIQ IRQ enable/disable function will case system
> hang. The root cause is, in the sequence of function amdgpu_fini, the sw_fini
> of IP block AMD_IP_BLOCK_TYPE_GFX will be invoked earlier than that of
> AMD_IP_BLOCK_TYPE_IH. So continue to use the variable freed by
> AMD_IP_BLOCK_TYPE_GFX will cause system hang.
> 
> Signed-off-by: Trigger Huang <trigger.hu...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 ++
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 17 -
>  2 files changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 1db2e7b..be43d09 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -793,6 +793,8 @@ struct amdgpu_kiq {
>   struct amdgpu_bo*eop_obj;
>   struct amdgpu_ring  ring;
>   struct amdgpu_irq_src   irq;
> + u32 me;
> + u32 pipe;
>  };
> 
>  /*
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 772c42b..04e2a5b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -1390,12 +1390,15 @@ static int gfx_v8_0_kiq_init_ring(struct
> amdgpu_device *adev,
>   if (adev->gfx.mec2_fw) {
>   ring->me = 2;
>   ring->pipe = 0;
> + adev->gfx.kiq.me = 2;
> + adev->gfx.kiq.pipe = 0;
>   } else {
>   ring->me = 1;
>   ring->pipe = 1;
> + adev->gfx.kiq.me = 1;
> + adev->gfx.kiq.pipe = 1;
>   }
> 
> - irq->data = ring;
>   ring->queue = 0;
>   sprintf(ring->name, "kiq %d.%d.%d", ring->me, ring->pipe, ring-
> >queue);
>   r = amdgpu_ring_init(adev, ring, 1024, @@ -1410,7 +1413,6 @@ static
> void gfx_v8_0_kiq_free_ring(struct amdgpu_ring *ring,  {
>   amdgpu_wb_free(ring->adev, ring->adev->virt.reg_val_offs);
>   amdgpu_ring_fini(ring);
> - irq->data = NULL;
>  }
> 
>  #define MEC_HPD_SIZE 2048
> @@ -6927,15 +6929,12 @@ static int
> gfx_v8_0_kiq_set_interrupt_state(struct amdgpu_device *adev,
>   enum amdgpu_interrupt_state
> state)  {
>   uint32_t tmp, target;
> - struct amdgpu_ring *ring = (struct amdgpu_ring *)src->data;
> 
> - BUG_ON(!ring || (ring->funcs->type != AMDGPU_RING_TYPE_KIQ));
> -
> - if (ring->me == 1)
> + if (adev->gfx.kiq.me == 1)
>   target = mmCP_ME1_PIPE0_INT_CNTL;
>   else
>   target = mmCP_ME2_PIPE0_INT_CNTL;
> - target += ring->pipe;
> + target += adev->gfx.kiq.pipe;
> 
>   switch (type) {
>   case AMDGPU_CP_KIQ_IRQ_DRIVER0:
> @@ -6973,7 +6972,7 @@ static int gfx_v8_0_kiq_irq(struct amdgpu_device
> *adev,
>   struct amdgpu_iv_entry *entry)
>  {
>   u8 me_id, pipe_id, queue_id;
> - struct amdgpu_ring *ring = (struct amdgpu_ring *)source->data;
> + struct amdgpu_ring *ring = &(adev->gfx.kiq.ring);
> 
>   BUG_ON(!ring || (ring->funcs->type != AMDGPU_RING_TYPE_KIQ));
> 
> @@ -7380,4 +7379,4 @@ static void
> gfx_v8_0_compute_mqd_soft_fini(struct amdgpu_device *adev)
> 
>   ring = >gfx.kiq.ring;
>   amdgpu_bo_free_kernel(>mqd_obj, >mqd_gpu_addr,
> (void **)>mqd_ptr); -} \ No newline at end of file
> +}
> --
> 2.7.4

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


RE: [PATCH 11/11] drm/amdgpu:fix kiq_resume routine (V2)

2017-02-08 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>



Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH 11/11] drm/amdgpu:fix kiq_resume routine (V2)
> 
> v2:
> use in_rest to fix compute ring test failure issue which occured after
> FLR/gpu_reset.
> 
> we need backup a clean status of MQD which was created in drv load stage,
> and use it in resume stage, otherwise KCQ and KIQ all may faild in ring/ib 
> test.
> 
> Change-Id: I41be940454a6638e9a8a05f096601eaa1fbebaab
> Signed-off-by: Monk Liu <monk@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 ++
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 44
> ++
>  2 files changed, 35 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 5215fc5..afcae15 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2410,6 +2410,7 @@ int amdgpu_sriov_gpu_reset(struct
> amdgpu_device *adev, bool voluntary)
> 
>   mutex_lock(>virt.lock_reset);
>   atomic_inc(>gpu_reset_counter);
> + adev->gfx.in_reset = true;
> 
>   /* block TTM */
>   resched = ttm_bo_lock_delayed_workqueue(>mman.bdev);
> @@ -2494,6 +2495,7 @@ int amdgpu_sriov_gpu_reset(struct
> amdgpu_device *adev, bool voluntary)
>   dev_info(adev->dev, "GPU reset failed\n");
>   }
> 
> + adev->gfx.in_reset = false;
>   mutex_unlock(>virt.lock_reset);
>   return r;
>  }
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 6584173..1822420 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -4877,24 +4877,46 @@ static int gfx_v8_0_kiq_init_queue(struct
> amdgpu_ring *ring,
>   struct amdgpu_kiq *kiq = >gfx.kiq;
>   uint64_t eop_gpu_addr;
>   bool is_kiq = (ring->funcs->type == AMDGPU_RING_TYPE_KIQ);
> + int mqd_idx = AMDGPU_MAX_COMPUTE_RINGS;
> 
>   if (is_kiq) {
>   eop_gpu_addr = kiq->eop_gpu_addr;
>   gfx_v8_0_kiq_setting(>ring);
> - } else
> + } else {
>   eop_gpu_addr = adev->gfx.mec.hpd_eop_gpu_addr +
>   ring->queue * MEC_HPD_SIZE;
> + mqd_idx = ring - >gfx.compute_ring[0];
> + }
> 
> - mutex_lock(>srbm_mutex);
> - vi_srbm_select(adev, ring->me, ring->pipe, ring->queue, 0);
> + if (!adev->gfx.in_reset) {
> + memset((void *)mqd, 0, sizeof(*mqd));
> + mutex_lock(>srbm_mutex);
> + vi_srbm_select(adev, ring->me, ring->pipe, ring->queue, 0);
> + gfx_v8_0_mqd_init(adev, mqd, mqd_gpu_addr,
> eop_gpu_addr, ring);
> + if (is_kiq)
> + gfx_v8_0_kiq_init_register(adev, mqd, ring);
> + vi_srbm_select(adev, 0, 0, 0, 0);
> + mutex_unlock(>srbm_mutex);
> 
> - gfx_v8_0_mqd_init(adev, mqd, mqd_gpu_addr, eop_gpu_addr,
> ring);
> + if (adev->gfx.mec.mqd_backup[mqd_idx])
> + memcpy(adev->gfx.mec.mqd_backup[mqd_idx],
> mqd, sizeof(*mqd));
> + } else { /* for GPU_RESET case */
> + /* reset MQD to a clean status */
> + if (adev->gfx.mec.mqd_backup[mqd_idx])
> + memcpy(mqd, adev-
> >gfx.mec.mqd_backup[mqd_idx], sizeof(*mqd));
> 
> - if (is_kiq)
> - gfx_v8_0_kiq_init_register(adev, mqd, ring);
> -
> - vi_srbm_select(adev, 0, 0, 0, 0);
> - mutex_unlock(>srbm_mutex);
> + /* reset ring buffer */
> + ring->wptr = 0;
> + amdgpu_ring_clear_ring(ring);
> +
> + if (is_kiq) {
> + mutex_lock(>srbm_mutex);
> + vi_srbm_select(adev, ring->me, ring->pipe, ring->queue,
> 0);
> + gfx_v8_0_kiq_init_register(adev, mqd, ring);
> + vi_srbm_select(adev, 0, 0, 0, 0);
> + mutex_unlock(>srbm_mutex);
> + }
> + }
> 
>   if (is_kiq)
>   gfx_v8_0_kiq_enable(ring);
> @@ -4913,9 +4935,9 @@ static int gfx_v8_0_kiq_resume(struct
> amdgpu_device *adev)
> 
>   ring = >gfx.kiq.ring;
>   if (!amdgpu_bo_kmap(rin

RE: [PATCH 08/11] drm/amdgpu:alloc mqd backup

2017-02-08 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>




Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH 08/11] drm/amdgpu:alloc mqd backup
> 
> this is required for restoring the mqds after GPU reset.
> 
> Change-Id: I84f821faa657a5d942c33d30f206eb66b579c2f8
> Signed-off-by: Monk Liu <monk@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  1 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 10 ++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index acd9970..73086d0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -781,6 +781,7 @@ struct amdgpu_mec {
>   u32 num_pipe;
>   u32 num_mec;
>   u32 num_queue;
> + struct vi_mqd   *mqd_backup[AMDGPU_MAX_COMPUTE_RINGS +
> 1];
>  };
> 
>  struct amdgpu_kiq {
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 8f545992..b0612d1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -7309,6 +7309,11 @@ static int gfx_v8_0_compute_mqd_soft_init(struct
> amdgpu_device *adev)
>   dev_warn(adev->dev, "failed to create ring mqd ob
> (%d)", r);
>   return r;
>   }
> +
> + /* prepare MQD backup */
> + adev-
> >gfx.mec.mqd_backup[AMDGPU_MAX_COMPUTE_RINGS] =
> kmalloc(sizeof(struct vi_mqd), GFP_KERNEL);
> + if (!adev-
> >gfx.mec.mqd_backup[AMDGPU_MAX_COMPUTE_RINGS])
> + dev_warn(adev->dev, "no memory to create
> MQD backup for ring %s\n", ring->name);
>   }
> 
>   /* create MQD for each KCQ */
> @@ -7323,6 +7328,11 @@ static int gfx_v8_0_compute_mqd_soft_init(struct
> amdgpu_device *adev)
>   dev_warn(adev->dev, "failed to create ring
> mqd ob (%d)", r);
>   return r;
>   }
> +
> + /* prepare MQD backup */
> + adev->gfx.mec.mqd_backup[i] =
> kmalloc(sizeof(struct vi_mqd), GFP_KERNEL);
> + if (!adev->gfx.mec.mqd_backup[i])
> + dev_warn(adev->dev, "no memory to create
> MQD backup for ring %s\n", ring->name);
>   }
>   }
> 
> --
> 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 04/11] drm/amdgpu:no kiq for mailbox registers access

2017-02-08 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>



Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: [PATCH 04/11] drm/amdgpu:no kiq for mailbox registers access
> 
> Use no kiq version reg access due to:
> 1) better performance
> 2) INTR context consideration (some routine in mailbox is in
>INTR context e.g.xgpu_vi_mailbox_rcv_irq)
> 
> Change-Id: I383d7ce858a136d7b112180f86e3d632d37b4d1c
> Signed-off-by: Monk Liu <monk@amd.com>
> Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 32 
> 
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index b8edfe5..7c7420f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -321,12 +321,12 @@ static void xgpu_vi_mailbox_send_ack(struct
> amdgpu_device *adev)
>   int timeout = VI_MAILBOX_TIMEDOUT;
>   u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> 
> - reg = RREG32(mmMAILBOX_CONTROL);
> + reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
>   reg = REG_SET_FIELD(reg, MAILBOX_CONTROL, RCV_MSG_ACK, 1);
> - WREG32(mmMAILBOX_CONTROL, reg);
> + WREG32_NO_KIQ(mmMAILBOX_CONTROL, reg);
> 
>   /*Wait for RCV_MSG_VALID to be 0*/
> - reg = RREG32(mmMAILBOX_CONTROL);
> + reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
>   while (reg & mask) {
>   if (timeout <= 0) {
>   pr_err("RCV_MSG_VALID is not cleared\n"); @@ -
> 335,7 +335,7 @@ static void xgpu_vi_mailbox_send_ack(struct
> amdgpu_device *adev)
>   mdelay(1);
>   timeout -=1;
> 
> - reg = RREG32(mmMAILBOX_CONTROL);
> + reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
>   }
>  }
> 
> @@ -343,10 +343,10 @@ static void xgpu_vi_mailbox_set_valid(struct
> amdgpu_device *adev, bool val)  {
>   u32 reg;
> 
> - reg = RREG32(mmMAILBOX_CONTROL);
> + reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
>   reg = REG_SET_FIELD(reg, MAILBOX_CONTROL,
>   TRN_MSG_VALID, val ? 1 : 0);
> - WREG32(mmMAILBOX_CONTROL, reg);
> + WREG32_NO_KIQ(mmMAILBOX_CONTROL, reg);
>  }
> 
>  static void xgpu_vi_mailbox_trans_msg(struct amdgpu_device *adev, @@ -
> 354,10 +354,10 @@ static void xgpu_vi_mailbox_trans_msg(struct
> amdgpu_device *adev,  {
>   u32 reg;
> 
> - reg = RREG32(mmMAILBOX_MSGBUF_TRN_DW0);
> + reg = RREG32_NO_KIQ(mmMAILBOX_MSGBUF_TRN_DW0);
>   reg = REG_SET_FIELD(reg, MAILBOX_MSGBUF_TRN_DW0,
>   MSGBUF_DATA, event);
> - WREG32(mmMAILBOX_MSGBUF_TRN_DW0, reg);
> + WREG32_NO_KIQ(mmMAILBOX_MSGBUF_TRN_DW0, reg);
> 
>   xgpu_vi_mailbox_set_valid(adev, true);  } @@ -368,11 +368,11 @@
> static int xgpu_vi_mailbox_rcv_msg(struct amdgpu_device *adev,
>   u32 reg;
>   u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> 
> - reg = RREG32(mmMAILBOX_CONTROL);
> + reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
>   if (!(reg & mask))
>   return -ENOENT;
> 
> - reg = RREG32(mmMAILBOX_MSGBUF_RCV_DW0);
> + reg = RREG32_NO_KIQ(mmMAILBOX_MSGBUF_RCV_DW0);
>   if (reg != event)
>   return -ENOENT;
> 
> @@ -388,7 +388,7 @@ static int xgpu_vi_poll_ack(struct amdgpu_device
> *adev)
>   u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL, TRN_MSG_ACK);
>   u32 reg;
> 
> - reg = RREG32(mmMAILBOX_CONTROL);
> + reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
>   while (!(reg & mask)) {
>   if (timeout <= 0) {
>   pr_err("Doesn't get ack from pf.\n"); @@ -398,7
> +398,7 @@ static int xgpu_vi_poll_ack(struct amdgpu_device *adev)
>   msleep(1);
>   timeout -= 1;
> 
> - reg = RREG32(mmMAILBOX_CONTROL);
> + reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
>   }
> 
>   return r;
> @@ -490,11 +490,11 @@ static int xgpu_vi_set_mailbox_ack_irq(struct
> amdgpu_device *adev,
>  unsigned type,
>  enum amdgpu_interrupt_state state)  {
> - u32 tmp = RREG32(mmMAILBOX_INT_CNTL);
> + u32 tmp = RREG32_NO_KIQ(mmMAILBOX_INT_CNTL);
> 
>   tmp = REG_SET_FIELD(tmp, MAILBOX_INT_CNTL, ACK_INT_EN,
&g

RE: [PATCH 03/11] drm/amdgpu:Refine handshake of mailbox

2017-02-08 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Xue, Ken <ken@amd.com>
> Subject: [PATCH 03/11] drm/amdgpu:Refine handshake of mailbox
> 
> From: Ken Xue <ken@amd.com>
> 
> Change-Id: If3a7d05824847234759b86563e8052949e171972
> Signed-off-by: Ken Xue <ken@amd.com>
> Acked-by: Alex Deucher <alexander.deuc...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 24
> +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index d2622b6..b8edfe5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -318,10 +318,25 @@ void xgpu_vi_init_golden_registers(struct
> amdgpu_device *adev)  static void xgpu_vi_mailbox_send_ack(struct
> amdgpu_device *adev)  {
>   u32 reg;
> + int timeout = VI_MAILBOX_TIMEDOUT;
> + u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> 
>   reg = RREG32(mmMAILBOX_CONTROL);
>   reg = REG_SET_FIELD(reg, MAILBOX_CONTROL, RCV_MSG_ACK, 1);
>   WREG32(mmMAILBOX_CONTROL, reg);
> +
> + /*Wait for RCV_MSG_VALID to be 0*/
> + reg = RREG32(mmMAILBOX_CONTROL);
> + while (reg & mask) {
> + if (timeout <= 0) {
> + pr_err("RCV_MSG_VALID is not cleared\n");
> + break;
> + }
> + mdelay(1);
> + timeout -=1;
> +
> + reg = RREG32(mmMAILBOX_CONTROL);
> + }
>  }
> 
>  static void xgpu_vi_mailbox_set_valid(struct amdgpu_device *adev, bool val)
> @@ -351,6 +366,11 @@ static int xgpu_vi_mailbox_rcv_msg(struct
> amdgpu_device *adev,
>  enum idh_event event)
>  {
>   u32 reg;
> + u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> +
> + reg = RREG32(mmMAILBOX_CONTROL);
> + if (!(reg & mask))
> + return -ENOENT;
> 
>   reg = RREG32(mmMAILBOX_MSGBUF_RCV_DW0);
>   if (reg != event)
> @@ -419,7 +439,9 @@ static int xgpu_vi_send_access_requests(struct
> amdgpu_device *adev,
>   xgpu_vi_mailbox_set_valid(adev, false);
> 
>   /* start to check msg if request is idh_req_gpu_init_access */
> - if (request == IDH_REQ_GPU_INIT_ACCESS) {
> + if (request == IDH_REQ_GPU_INIT_ACCESS ||
> + request == IDH_REQ_GPU_FINI_ACCESS ||
> + request == IDH_REQ_GPU_RESET_ACCESS) {
>   r = xgpu_vi_poll_msg(adev, IDH_READY_TO_ACCESS_GPU);
>   if (r)
>   return r;
> --
> 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 02/11] drm/amdgpu:impl RREG32 no kiq version

2017-02-08 Thread Yu, Xiangliang
Reviewed-by: Xiangliang.Yu 


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: [PATCH 02/11] drm/amdgpu:impl RREG32 no kiq version
> 
> some registers are PF & VF copy, and we can safely use mmio method to
> access them.
> 
> and sometime we are forbid to use kiq to access registers for example in
> INTR context.
> 
> we need a MACRO that always disable KIQ for regs accessing
> 
> Change-Id: Ie6dc323dc86829a4a6ceb7073c269b106b534c4a
> Signed-off-by: Monk Liu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h| 21 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 ++--
>  2 files changed, 20 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 402a895..74bffca8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1510,9 +1510,9 @@ void amdgpu_device_fini(struct amdgpu_device
> *adev);  int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
> 
>  uint32_t amdgpu_mm_rreg(struct amdgpu_device *adev, uint32_t reg,
> - bool always_indirect);
> + uint32_t acc_flags);
>  void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg,
> uint32_t v,
> - bool always_indirect);
> + uint32_t acc_flags);
>  u32 amdgpu_io_rreg(struct amdgpu_device *adev, u32 reg);  void
> amdgpu_io_wreg(struct amdgpu_device *adev, u32 reg, u32 v);
> 
> @@ -1523,11 +1523,18 @@ bool amdgpu_device_has_dc_support(struct
> amdgpu_device *adev);
>  /*
>   * Registers read & write functions.
>   */
> -#define RREG32(reg) amdgpu_mm_rreg(adev, (reg), false) -#define
> RREG32_IDX(reg) amdgpu_mm_rreg(adev, (reg), true) -#define DREG32(reg)
> printk(KERN_INFO "REGISTER: " #reg " : 0x%08X\n", amdgpu_mm_rreg(adev,
> (reg), false)) -#define WREG32(reg, v) amdgpu_mm_wreg(adev, (reg), (v),
> false) -#define WREG32_IDX(reg, v) amdgpu_mm_wreg(adev, (reg), (v),
> true)
> +
> +#define AMDGPU_REGS_IDX   (1<<0)
> +#define AMDGPU_REGS_NO_KIQ(1<<1)
> +
> +#define RREG32_NO_KIQ(reg) amdgpu_mm_rreg(adev, (reg),
> +AMDGPU_REGS_NO_KIQ) #define WREG32_NO_KIQ(reg, v)
> amdgpu_mm_wreg(adev,
> +(reg), (v), AMDGPU_REGS_NO_KIQ)
> +
> +#define RREG32(reg) amdgpu_mm_rreg(adev, (reg), 0) #define
> +RREG32_IDX(reg) amdgpu_mm_rreg(adev, (reg), AMDGPU_REGS_IDX)
> #define
> +DREG32(reg) printk(KERN_INFO "REGISTER: " #reg " : 0x%08X\n",
> +amdgpu_mm_rreg(adev, (reg), 0)) #define WREG32(reg, v)
> +amdgpu_mm_wreg(adev, (reg), (v), 0) #define WREG32_IDX(reg, v)
> +amdgpu_mm_wreg(adev, (reg), (v), AMDGPU_REGS_IDX)
>  #define REG_SET(FIELD, v) (((v) << FIELD##_SHIFT) & FIELD##_MASK)
> #define REG_GET(FIELD, v) (((v) << FIELD##_SHIFT) & FIELD##_MASK)
> #define RREG32_PCIE(reg) adev->pcie_rreg(adev, (reg)) diff --git
> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 3534089..5215fc5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -91,16 +91,16 @@ bool amdgpu_device_is_px(struct drm_device *dev)
>   * MMIO register access helper functions.
>   */
>  uint32_t amdgpu_mm_rreg(struct amdgpu_device *adev, uint32_t reg,
> - bool always_indirect)
> + uint32_t acc_flags)
>  {
>   uint32_t ret;
> 
> - if (amdgpu_sriov_runtime(adev)) {
> + if (!(acc_flags & AMDGPU_REGS_NO_KIQ) &&
> amdgpu_sriov_runtime(adev)) {
>   BUG_ON(in_interrupt());
>   return amdgpu_virt_kiq_rreg(adev, reg);
>   }
> 
> - if ((reg * 4) < adev->rmmio_size && !always_indirect)
> + if ((reg * 4) < adev->rmmio_size && !(acc_flags &
> AMDGPU_REGS_IDX))
>   ret = readl(((void __iomem *)adev->rmmio) + (reg * 4));
>   else {
>   unsigned long flags;
> @@ -115,16 +115,16 @@ uint32_t amdgpu_mm_rreg(struct amdgpu_device
> *adev, uint32_t reg,  }
> 
>  void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg,
> uint32_t v,
> - bool always_indirect)
> + uint32_t acc_flags)
>  {
>   trace_amdgpu_mm_wreg(adev->pdev->device, reg, v);
> 
> - if (amdgpu_sriov_runtime(adev)) {
> + if (!(acc_flags & AMDGPU_REGS_NO_KIQ) &&
> amdgpu_sriov_runtime(adev)) {
>   BUG_ON(in_interrupt());
>   return amdgpu_virt_kiq_wreg(adev, reg, v);
>   }
> 
> - if ((reg * 4) < adev->rmmio_size && !always_indirect)
> + if ((reg * 4) < adev->rmmio_size && !(acc_flags &
> AMDGPU_REGS_IDX))
>   writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
>   else {
>   unsigned long flags;
> --
> 2.7.4
> 
> ___
> amd-gfx 

RE: [PATCH 05/11] drm/amdgpu:use work instead of delay-work

2017-02-08 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu 


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, February 08, 2017 5:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: [PATCH 05/11] drm/amdgpu:use work instead of delay-work
> 
> no need to use a delay work since we don't know how much time hypervisor
> takes on FLR, so just polling and waiting in a work.
> 
> Change-Id: I41b6336baa00b1fd299311349402a17951b585a2
> Signed-off-by: Monk Liu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |  2 +-
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c| 36 +++
> -
>  2 files changed, 18 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> index 4b05568..846f29c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> @@ -50,7 +50,7 @@ struct amdgpu_virt {
>   struct mutexlock_reset;
>   struct amdgpu_irq_src   ack_irq;
>   struct amdgpu_irq_src   rcv_irq;
> - struct delayed_work flr_work;
> + struct work_struct  flr_work;
>   const struct amdgpu_virt_ops*ops;
>  };
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index 7c7420f..5f156d3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -501,17 +501,19 @@ static int xgpu_vi_set_mailbox_ack_irq(struct
> amdgpu_device *adev,
> 
>  static void xgpu_vi_mailbox_flr_work(struct work_struct *work)  {
> - struct amdgpu_virt *virt = container_of(work,
> - struct amdgpu_virt, flr_work.work);
> - struct amdgpu_device *adev = container_of(virt,
> - struct amdgpu_device, virt);
> - int r = 0;
> -
> - r = xgpu_vi_poll_msg(adev, IDH_FLR_NOTIFICATION_CMPL);
> - if (r)
> - DRM_ERROR("failed to get flr cmpl msg from hypervior.\n");
> + struct amdgpu_virt *virt = container_of(work, struct amdgpu_virt,
> flr_work);
> + struct amdgpu_device *adev = container_of(virt, struct
> amdgpu_device,
> +virt);
> +
> + /* wait until RCV_MSG become 3 */
> + if (!xgpu_vi_poll_msg(adev, IDH_FLR_NOTIFICATION_CMPL))
> + adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> + else {
> + pr_err("failed to recieve FLR_CMPL\n");
> + return;
> + }
> 
> - /* TODO: need to restore gfx states */
> + /* Trigger recovery due to world switch failure */
> + amdgpu_sriov_gpu_reset(adev, false);
>  }
> 
>  static int xgpu_vi_set_mailbox_rcv_irq(struct amdgpu_device *adev, @@ -
> 534,15 +536,12 @@ static int xgpu_vi_mailbox_rcv_irq(struct amdgpu_device
> *adev,  {
>   int r;
> 
> - adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> + /* see what event we get */
>   r = xgpu_vi_mailbox_rcv_msg(adev, IDH_FLR_NOTIFICATION);
> - /* do nothing for other msg */
> - if (r)
> - return 0;
> 
> - /* TODO: need to save gfx states */
> - schedule_delayed_work(>virt.flr_work,
> -   msecs_to_jiffies(VI_MAILBOX_RESET_TIME));
> + /* only handle FLR_NOTIFY now */
> + if (!r)
> + schedule_work(>virt.flr_work);
> 
>   return 0;
>  }
> @@ -595,14 +594,13 @@ int xgpu_vi_mailbox_get_irq(struct
> amdgpu_device *adev)
>   return r;
>   }
> 
> - INIT_DELAYED_WORK(>virt.flr_work,
> xgpu_vi_mailbox_flr_work);
> + INIT_WORK(>virt.flr_work, xgpu_vi_mailbox_flr_work);
> 
>   return 0;
>  }
> 
>  void xgpu_vi_mailbox_put_irq(struct amdgpu_device *adev)  {
> - cancel_delayed_work_sync(>virt.flr_work);
>   amdgpu_irq_put(adev, >virt.ack_irq, 0);
>   amdgpu_irq_put(adev, >virt.rcv_irq, 0);  }
> --
> 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 12/20] drm/amdgpu:impl mm_r/weg_nokiq

2017-02-07 Thread Yu, Xiangliang
> > +uint32_t amdgpu_mm_rreg_nokiq(struct amdgpu_device *adev, uint32_t
> > reg,
> > +   bool always_indirect)
> > +{
> > +   uint32_t ret;
> > +
> > +   if ((reg * 4) < adev->rmmio_size && !always_indirect)
> > +   ret = readl(((void __iomem *)adev->rmmio) + (reg * 4));
> > +   else {
> > +   unsigned long flags;
> > +
> > +   spin_lock_irqsave(>mmio_idx_lock, flags);
> > +   writel((reg * 4), ((void __iomem *)adev->rmmio) +
> > (mmMM_INDEX * 4));
> > +   ret = readl(((void __iomem *)adev->rmmio) +
> > (mmMM_DATA * 4));
> > +   spin_unlock_irqrestore(>mmio_idx_lock, flags);
> > +   }
> > +   trace_amdgpu_mm_rreg(adev->pdev->device, reg, ret);
> > +   return ret;
> > +}
> > +
> > +void amdgpu_mm_wreg_nokiq(struct amdgpu_device *adev, uint32_t
> reg,
> > uint32_t v,
> > +   bool always_indirect)
> > +{
> > +   trace_amdgpu_mm_wreg(adev->pdev->device, reg, v);
> > +
> > +   if ((reg * 4) < adev->rmmio_size && !always_indirect)
> > +   writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
> > +   else {
> > +   unsigned long flags;
> > +
> > +   spin_lock_irqsave(>mmio_idx_lock, flags);
> > +   writel((reg * 4), ((void __iomem *)adev->rmmio) +
> > (mmMM_INDEX * 4));
> > +   writel(v, ((void __iomem *)adev->rmmio) + (mmMM_DATA
> > * 4));
> > +   spin_unlock_irqrestore(>mmio_idx_lock, flags);
> > +   }
> > +}
> 
> These are duplicated with the regular mm_rreg and mm_wreg functions.
> Maybe add a new parameter to the existing functions to bypass kiq in the sr-
> iov case?

Why not re-use always_indirect flag to check kiq path, I think kiq read 
register is also indirect way to get register value.

> 
> > +
> >  u32 amdgpu_io_rreg(struct amdgpu_device *adev, u32 reg)  {
> > if ((reg * 4) < adev->rio_mem_size)
> > --
> > 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
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH 15/20] drm/amdgpu:use work instead of delay-work

2017-02-07 Thread Yu, Xiangliang
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Deucher, Alexander
> Sent: Wednesday, February 08, 2017 12:11 AM
> To: Liu, Monk ; amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: RE: [PATCH 15/20] drm/amdgpu:use work instead of delay-work
> 
> > -Original Message-
> > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Monk Liu
> > Sent: Tuesday, February 07, 2017 1:11 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Liu, Monk
> > Subject: [PATCH 15/20] drm/amdgpu:use work instead of delay-work
> >
> > Change-Id: I41b6336baa00b1fd299311349402a17951b585a2
> > Signed-off-by: Monk Liu 
> 
> Please add a better patch description.  Why is this change needed?

My initial version will start two works to handle flr events: one is for flr 
notify irq and the other is for flr completion irq and will be called delay 
work.

According to the monk's version, there is only one work to handle all flr 
events. If so, I think it is also make sense.


> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |  2 +-
> >  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c| 36 +++--
> --
> > -
> >  2 files changed, 18 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > index 4b05568..846f29c 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > @@ -50,7 +50,7 @@ struct amdgpu_virt {
> > struct mutexlock_reset;
> > struct amdgpu_irq_src   ack_irq;
> > struct amdgpu_irq_src   rcv_irq;
> > -   struct delayed_work flr_work;
> > +   struct work_struct  flr_work;
> > const struct amdgpu_virt_ops*ops;
> >  };
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > index 4e9e0bb..53fa590c 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > @@ -503,17 +503,19 @@ static int xgpu_vi_set_mailbox_ack_irq(struct
> > amdgpu_device *adev,
> >
> >  static void xgpu_vi_mailbox_flr_work(struct work_struct *work)  {
> > -   struct amdgpu_virt *virt = container_of(work,
> > -   struct amdgpu_virt, flr_work.work);
> > -   struct amdgpu_device *adev = container_of(virt,
> > -   struct amdgpu_device, virt);
> > -   int r = 0;
> > -
> > -   r = xgpu_vi_poll_msg(adev, IDH_FLR_NOTIFICATION_CMPL);
> > -   if (r)
> > -   DRM_ERROR("failed to get flr cmpl msg from hypervior.\n");
> > +   struct amdgpu_virt *virt = container_of(work, struct amdgpu_virt,
> > flr_work);
> > +   struct amdgpu_device *adev = container_of(virt, struct
> > amdgpu_device, virt);
> > +
> > +   /* wait until RCV_MSG become 3 */
> > +   if (!xgpu_vi_poll_msg(adev, IDH_FLR_NOTIFICATION_CMPL))
> > +   adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> > +   else {
> > +   pr_err("failed to recieve FLR_CMPL\n");
> > +   return;
> > +   }
> >
> > -   /* TODO: need to restore gfx states */
> > +   /* Trigger recovery due to world switch failure */
> > +   amdgpu_sriov_gpu_reset(adev, false);
> >  }
> >
> >  static int xgpu_vi_set_mailbox_rcv_irq(struct amdgpu_device *adev, @@
> > -536,15 +538,12 @@ static int xgpu_vi_mailbox_rcv_irq(struct
> > amdgpu_device *adev,  {
> > int r;
> >
> > -   adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> > +   /* see what event we get */
> > r = xgpu_vi_mailbox_rcv_msg(adev, IDH_FLR_NOTIFICATION);
> > -   /* do nothing for other msg */
> > -   if (r)
> > -   return 0;
> >
> > -   /* TODO: need to save gfx states */
> > -   schedule_delayed_work(>virt.flr_work,
> > - msecs_to_jiffies(VI_MAILBOX_RESET_TIME));
> > +   /* only handle FLR_NOTIFY now */
> > +   if (!r)
> > +   schedule_work(>virt.flr_work);
> >
> > return 0;
> >  }
> > @@ -597,14 +596,13 @@ int xgpu_vi_mailbox_get_irq(struct
> amdgpu_device
> > *adev)
> > return r;
> > }
> >
> > -   INIT_DELAYED_WORK(>virt.flr_work,
> > xgpu_vi_mailbox_flr_work);
> > +   INIT_WORK(>virt.flr_work, xgpu_vi_mailbox_flr_work);
> >
> > return 0;
> >  }
> >
> >  void xgpu_vi_mailbox_put_irq(struct amdgpu_device *adev)  {
> > -   cancel_delayed_work_sync(>virt.flr_work);
> > amdgpu_irq_put(adev, >virt.ack_irq, 0);
> > amdgpu_irq_put(adev, >virt.rcv_irq, 0);  }
> > --
> > 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: [bug report] drm/amdgpu/virt: implement VI virt operation interfaces

2017-02-06 Thread Yu, Xiangliang
Thanks! I'll fix it.


Thanks!
Xiangliang Yu


> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Monday, February 06, 2017 7:19 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx@lists.freedesktop.org
> Subject: [bug report] drm/amdgpu/virt: implement VI virt operation
> interfaces
> 
> Hello Xiangliang Yu,
> 
> The patch ab71ac56f6d8: "drm/amdgpu/virt: implement VI virt operation
> interfaces" from Jan 12, 2017, leads to the following static checker
> warning:
> 
>   drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c:310
> xgpu_vi_init_golden_registers()
>   warn: string literals are always true.
> 
> drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
>294  break;
>295  case CHIP_TONGA:
>296  amdgpu_program_register_sequence(adev,
>297   
> xgpu_tonga_mgcg_cgcg_init,
>298   (const 
> u32)ARRAY_SIZE(
>299   
> xgpu_tonga_mgcg_cgcg_init));
>300  amdgpu_program_register_sequence(adev,
>301   
> xgpu_tonga_golden_settings_a11,
>302   (const 
> u32)ARRAY_SIZE(
>303   
> xgpu_tonga_golden_settings_a11));
>304  amdgpu_program_register_sequence(adev,
>305   
> xgpu_tonga_golden_common_all,
>306   (const 
> u32)ARRAY_SIZE(
>307   
> xgpu_tonga_golden_common_all));
>308  break;
>309  default:
>310  BUG_ON("Doesn't support chip type.\n");
> 
> BUG_ON() takes a condition argument, not a format string.
> 
>311  break;
>312  }
>313  }
> 
> regards,
> dan carpenter
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH 1/2] drm/amdgpu: don't clean the framebuffer for VF

2017-02-05 Thread Yu, Xiangliang
Acked-by: Xiangliang.Yu 


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, February 06, 2017 2:25 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Ding, Pixel ; ding.pi...@amd.com
> Subject: [PATCH 1/2] drm/amdgpu: don't clean the framebuffer for VF
> 
> The SRIOV host driver cleans framebuffer for each VF, guest driver needn't
> this action which costs much time on some virtualization platform, otherwise
> it might get timeout to initialize.
> 
> Signed-off-by: Pixel Ding 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 1e735c4..f1eb4f5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -242,7 +242,9 @@ static int amdgpufb_create(struct drm_fb_helper
> *helper,
>   /* setup helper */
>   rfbdev->helper.fb = fb;
> 
> - memset_io(abo->kptr, 0x0, amdgpu_bo_size(abo));
> + if (!amdgpu_sriov_vf(adev)) {
> + memset_io(abo->kptr, 0x0, amdgpu_bo_size(abo));
> + }
> 
>   strcpy(info->fix.id, "amdgpudrmfb");
> 
> --
> 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 1/2] drm/amdgpu/virt: refine handshake between guest and host by mailbox

2017-02-05 Thread Yu, Xiangliang
Reviewed-by: Xiangliang.Yu 


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, February 06, 2017 3:00 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Xue, Ken 
> Subject: [PATCH 1/2] drm/amdgpu/virt: refine handshake between guest
> and host by mailbox
> 
> From: Ken Xue 
> 
> The previous handshake doesn't check the VALID flag for mailbox. A bug
> occurs that the driver believes it's in exclusive mode but actually it's not, 
> then
> the subsequent initliaztion fails.
> 
> The right protocol should be that guest driver checks VALID flag and makes
> sure the host driver has already recieved the ACK message and handle it like:
> 
> A: send MSG->  clear VALID->
> B:   send ACK-> check VALID
> 
> Signed-off-by: Ken Xue 
> Acked-by: Pixel Ding 
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 26
> +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index d2622b6..5fe4aad 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -318,10 +318,25 @@ void xgpu_vi_init_golden_registers(struct
> amdgpu_device *adev)  static void xgpu_vi_mailbox_send_ack(struct
> amdgpu_device *adev)  {
>   u32 reg;
> + int timeout = VI_MAILBOX_TIMEDOUT;
> + u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> 
>   reg = RREG32(mmMAILBOX_CONTROL);
>   reg = REG_SET_FIELD(reg, MAILBOX_CONTROL, RCV_MSG_ACK, 1);
>   WREG32(mmMAILBOX_CONTROL, reg);
> +
> + /*Wait for RCV_MSG_VALID to be 0*/
> + reg = RREG32(mmMAILBOX_CONTROL);
> + while (reg & mask) {
> + if (timeout <= 0) {
> + pr_err("RCV_MSG_VALID is not cleared\n");
> + break;
> + }
> + mdelay(1);
> + timeout -=1;
> +
> + reg = RREG32(mmMAILBOX_CONTROL);
> + }
>  }
> 
>  static void xgpu_vi_mailbox_set_valid(struct amdgpu_device *adev, bool val)
> @@ -339,6 +354,8 @@ static void xgpu_vi_mailbox_trans_msg(struct
> amdgpu_device *adev,  {
>   u32 reg;
> 
> + xgpu_vi_mailbox_send_ack(adev);
> +
>   reg = RREG32(mmMAILBOX_MSGBUF_TRN_DW0);
>   reg = REG_SET_FIELD(reg, MAILBOX_MSGBUF_TRN_DW0,
>   MSGBUF_DATA, event);
> @@ -351,6 +368,11 @@ static int xgpu_vi_mailbox_rcv_msg(struct
> amdgpu_device *adev,
>  enum idh_event event)
>  {
>   u32 reg;
> + u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> +
> + reg = RREG32(mmMAILBOX_CONTROL);
> + if (!(reg & mask))
> + return -ENOENT;
> 
>   reg = RREG32(mmMAILBOX_MSGBUF_RCV_DW0);
>   if (reg != event)
> @@ -419,7 +441,9 @@ static int xgpu_vi_send_access_requests(struct
> amdgpu_device *adev,
>   xgpu_vi_mailbox_set_valid(adev, false);
> 
>   /* start to check msg if request is idh_req_gpu_init_access */
> - if (request == IDH_REQ_GPU_INIT_ACCESS) {
> + if (request == IDH_REQ_GPU_INIT_ACCESS ||
> + request == IDH_REQ_GPU_FINI_ACCESS ||
> + request == IDH_REQ_GPU_RESET_ACCESS) {
>   r = xgpu_vi_poll_msg(adev, IDH_READY_TO_ACCESS_GPU);
>   if (r)
>   return r;
> --
> 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 2/2] drm/amdgpu: increase mailbox timeout to 5000ms

2017-02-05 Thread Yu, Xiangliang
Reviewed-by: Xiangliang Yu <xiangliang...@amd.com>


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Monday, February 06, 2017 2:25 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Ding, Pixel <pixel.d...@amd.com>; ding.pi...@amd.com
> Subject: [PATCH 2/2] drm/amdgpu: increase mailbox timeout to 5000ms
> 
> When mutiple VFs try to enter exclusive mode at the same time, the looping
> mechansim doesn't help to ensure each can get it because it only loops active
> VFs, then the last one has to wait for a long interval.
> 
> Signed-off-by: Pixel Ding <pixel.d...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> index fd6216e..2db7411 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> @@ -23,7 +23,7 @@
>  #ifndef __MXGPU_VI_H__
>  #define __MXGPU_VI_H__
> 
> -#define VI_MAILBOX_TIMEDOUT  150
> +#define VI_MAILBOX_TIMEDOUT  5000
>  #define VI_MAILBOX_RESET_TIME12
> 
>  /* VI mailbox messages request */
> --
> 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 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from VF

2017-02-05 Thread Yu, Xiangliang
Have you tried the patch for unloading driver?

Ps:  the index of patch make people confused, I think there are 21 patches in 
the series.


Thanks!
Xiangliang Yu


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Saturday, February 04, 2017 6:35 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: [PATCH 05/21] drm/amdgpu:BUG if gpu_reste and asic_reset from
> VF
> 
> for SRIOV vf, Guest couldn't really access PCI registers so
> gpu_reset() and asic_reset should be avoided.
> 
> for suspend it could run for SRIOV because cg/pg routine already modified
> for SRIOV vf case, besides we should remove the req/rel gpu access around
> it because the req/rel should be used by invoker.
> 
> Change-Id: I678d3f2ce202458c1d1d404970fa47421766b666
> Signed-off-by: Monk Liu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +
>  drivers/gpu/drm/amd/amdgpu/vi.c| 2 ++
>  2 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 6106cd6..173df73 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1566,9 +1566,6 @@ int amdgpu_suspend(struct amdgpu_device *adev)
> {
>   int i, r;
> 
> - if (amdgpu_sriov_vf(adev))
> - amdgpu_virt_request_full_gpu(adev, false);
> -
>   /* ungate SMC block first */
>   r = amdgpu_set_clockgating_state(adev,
> AMD_IP_BLOCK_TYPE_SMC,
>AMD_CG_STATE_UNGATE);
> @@ -1597,9 +1594,6 @@ int amdgpu_suspend(struct amdgpu_device *adev)
>   }
>   }
> 
> - if (amdgpu_sriov_vf(adev))
> - amdgpu_virt_release_full_gpu(adev, false);
> -
>   return 0;
>  }
> 
> @@ -2356,8 +2350,7 @@ int amdgpu_gpu_reset(struct amdgpu_device
> *adev)
>   int resched;
>   bool need_full_reset;
> 
> - if (amdgpu_sriov_vf(adev))
> - return 0;
> + BUG_ON(amdgpu_sriov_vf(adev));
> 
>   if (!amdgpu_check_soft_reset(adev)) {
>   DRM_INFO("No hardware hang detected. Did some blocks
> stall?\n"); diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index 7810030..557994c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -739,6 +739,8 @@ static int vi_asic_reset(struct amdgpu_device *adev)
> {
>   int r;
> 
> + BUG_ON(amdgpu_sriov_vf(adev));
> +
>   amdgpu_atombios_scratch_regs_engine_hung(adev, true);
> 
>   r = vi_gpu_pci_config_reset(adev);
> --
> 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 02/21] drm/amdgpu:fix golden init for sriov

2017-02-05 Thread Yu, Xiangliang
Does FIJI need the golden init?


Thanks!
Xiangliang Yu

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Saturday, February 04, 2017 6:22 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk 
> Subject: [PATCH 02/21] drm/amdgpu:fix golden init for sriov
> 
> although only vi supports SRIOV now,but we shouldn't make code has such
> assumption.
> 
> Change-Id: Ie73c185dc2e7f64756253045b32cabe70d618d19
> Signed-off-by: Monk Liu 
> ---
>  drivers/gpu/drm/amd/amdgpu/vi.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index 89b0dfe..7810030 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -274,12 +274,6 @@ static void vi_init_golden_registers(struct
> amdgpu_device *adev)
>   /* Some of the registers might be dependent on GRBM_GFX_INDEX
> */
>   mutex_lock(>grbm_idx_mutex);
> 
> - if (amdgpu_sriov_vf(adev)) {
> - xgpu_vi_init_golden_registers(adev);
> - mutex_unlock(>grbm_idx_mutex);
> - return;
> - }
> -
>   switch (adev->asic_type) {
>   case CHIP_TOPAZ:
>   amdgpu_program_register_sequence(adev,
> @@ -292,7 +286,10 @@ static void vi_init_golden_registers(struct
> amdgpu_device *adev)
>(const
> u32)ARRAY_SIZE(fiji_mgcg_cgcg_init));
>   break;
>   case CHIP_TONGA:
> - amdgpu_program_register_sequence(adev,
> + if (amdgpu_sriov_vf(adev))
> + xgpu_vi_init_golden_registers(adev);
> + else
> + amdgpu_program_register_sequence(adev,
>tonga_mgcg_cgcg_init,
>(const
> u32)ARRAY_SIZE(tonga_mgcg_cgcg_init));
>   break;
> --
> 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: [V3 04/11] drm/amdgpu/virt: use kiq to access registers

2017-01-11 Thread Yu, Xiangliang
> -Original Message-
> From: Michel Dänzer [mailto:mic...@daenzer.net]
> Sent: Thursday, January 12, 2017 1:45 PM
> To: Liu, Monk <monk@amd.com>; Christian König
> <deathsim...@vodafone.de>; Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [V3 04/11] drm/amdgpu/virt: use kiq to access registers
> 
> On 12/01/17 12:21 PM, Liu, Monk wrote:
> >
> >if (in_interrupt())
> > BUG();
> 
> Current coding style is
> 
> BUG_ON(in_interrupt());
> 
> according to https://kernelnewbies.org/FAQ/BUG .

Got it. 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: [V3 06/11] drm/amdgpu/virt: implement VI virt operation interfaces

2017-01-11 Thread Yu, Xiangliang
> > We will discuss it tomorrow, I'm not sure of your approach right now
> >
> > We can stop running driver right after IDH_FLR_NOTIFICATION received
> > and continue driver right after IDH_FLR_NOTIFICATION_CMPL

If missing the interrupt, I think we can't easy to handle the error. That what 
i want to avoid it.

> 
> > -Original Message-
> > From: Yu, Xiangliang
> > Sent: Wednesday, January 11, 2017 10:43 PM
> > To: Liu, Monk <monk@amd.com>; amd-gfx@lists.freedesktop.org
> > Cc: Liu, Shaoyun <shaoyun@amd.com>
> > Subject: RE: [V3 06/11] drm/amdgpu/virt: implement VI virt operation
> > interfaces
> >
> > > -Original Message-
> > > From: Liu, Monk
> > > Sent: Wednesday, January 11, 2017 10:28 PM
> > > To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> > > g...@lists.freedesktop.org
> > > Cc: Yu, Xiangliang <xiangliang...@amd.com>; Liu, Shaoyun
> > > <shaoyun@amd.com>
> > > Subject: RE: [V3 06/11] drm/amdgpu/virt: implement VI virt operation
> > > interfaces
> > >
> > > +static int xgpu_vi_mailbox_rcv_irq(struct amdgpu_device *adev,
> > > +struct amdgpu_irq_src *source,
> > > +struct amdgpu_iv_entry *entry) {
> > > + int r;
> > > +
> > > + adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> > > + r = xgpu_vi_mailbox_rcv_msg(adev, IDH_FLR_NOTIFICATION);
> > > + /* do nothing for other msg */
> > > + if (r)
> > > + return 0;
> > > +
> > > + /* TODO: need to save gfx states */
> > > + schedule_delayed_work(>virt.flr_work,
> > > +   msecs_to_jiffies(VI_MAILBOX_RESET_TIME));
> > > +
> > > + return 0;
> > > +}
> > >
> > > [ML] we should be able to receive at least two type of IRQ from mailbox:
> > > One is FLR_NOTIFICATION and another one is
> > IDH_FLR_NOTIFICATION_CMPL,
> > >
> > > The previous one means GIM told us GIM will start do FLR The later
> > > one means GIM told us GIM already finished FLR and from that on
> > > Guest driver can do re-initialize .
> > >
> > > You only handle the first IRQ, and dispatch a delay_work to monitor
> > > event of IDH_FLR_NOTIFICATION_CMPL,
> > >
> > > I suspect that correct scheme may be you handle both of those two
> > > type of IRQ , please check with @Frank and me on the detail tomorrow .
> >
> > As I think we may suspend gpu after receive FLR interrupt, polling
> > method is safer.
> >
> > >
> > > BR Monk
> > >
> > > -Original Message-
> > > From: Xiangliang Yu [mailto:xiangliang...@amd.com]
> > > Sent: Wednesday, January 11, 2017 9:18 PM
> > > To: amd-gfx@lists.freedesktop.org
> > > Cc: Yu, Xiangliang <xiangliang...@amd.com>; Liu, Monk
> > > <monk@amd.com>; Liu, Shaoyun <shaoyun@amd.com>
> > > Subject: [V3 06/11] drm/amdgpu/virt: implement VI virt operation
> > > interfaces
> > >
> > > VI has asic specific virt support, which including mailbox and
> > > golden registers init.
> > >
> > > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > > Signed-off-by: Monk Liu <monk@amd.com>
> > > Signed-off-by: shaoyunl <shaoyun@amd.com>
> > > ---
> > >  drivers/gpu/drm/amd/amdgpu/Makefile  |   2 +-
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |   9 +-
> > >  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c| 592
> > > +++
> > >  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h|  55 +++
> > >  4 files changed, 654 insertions(+), 4 deletions(-)  create mode
> > > 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > >  create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> > > b/drivers/gpu/drm/amd/amdgpu/Makefile
> > > index 0b8e470..388e7b0 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> > > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> > > @@ -40,7 +40,7 @@ amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o
> > cik_ih.o
> > > kv_smc.o kv_dpm.o \  amdgpu-$(CONFIG_DRM_AMDGPU_SI)+= si.o
> > gmc_v6_0.o
> > > gfx_v6_0.o si_ih.o si_dma.o dce_v6_0.o si_dpm.o si_smc.o
> > >
> > >  amdgpu-y += \
> > > - vi.o
> > > + vi.o mxgpu_vi.o
> > >
> > >  # add GMC block

RE: [V3 06/11] drm/amdgpu/virt: implement VI virt operation interfaces

2017-01-11 Thread Yu, Xiangliang
> We will discuss it tomorrow, I'm not sure of your approach right now
> 
> We can stop running driver right after IDH_FLR_NOTIFICATION received and
> continue driver right after IDH_FLR_NOTIFICATION_CMPL

I have verified the method on my platform and work fine.
Let's discuss it tomorrow if you have any concern.

> -Original Message-----
> From: Yu, Xiangliang
> Sent: Wednesday, January 11, 2017 10:43 PM
> To: Liu, Monk <monk@amd.com>; amd-gfx@lists.freedesktop.org
> Cc: Liu, Shaoyun <shaoyun@amd.com>
> Subject: RE: [V3 06/11] drm/amdgpu/virt: implement VI virt operation
> interfaces
> 
> > -Original Message-
> > From: Liu, Monk
> > Sent: Wednesday, January 11, 2017 10:28 PM
> > To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> > g...@lists.freedesktop.org
> > Cc: Yu, Xiangliang <xiangliang...@amd.com>; Liu, Shaoyun
> > <shaoyun@amd.com>
> > Subject: RE: [V3 06/11] drm/amdgpu/virt: implement VI virt operation
> > interfaces
> >
> > +static int xgpu_vi_mailbox_rcv_irq(struct amdgpu_device *adev,
> > +  struct amdgpu_irq_src *source,
> > +  struct amdgpu_iv_entry *entry) {
> > +   int r;
> > +
> > +   adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> > +   r = xgpu_vi_mailbox_rcv_msg(adev, IDH_FLR_NOTIFICATION);
> > +   /* do nothing for other msg */
> > +   if (r)
> > +   return 0;
> > +
> > +   /* TODO: need to save gfx states */
> > +   schedule_delayed_work(>virt.flr_work,
> > + msecs_to_jiffies(VI_MAILBOX_RESET_TIME));
> > +
> > +   return 0;
> > +}
> >
> > [ML] we should be able to receive at least two type of IRQ from mailbox:
> > One is FLR_NOTIFICATION and another one is
> IDH_FLR_NOTIFICATION_CMPL,
> >
> > The previous one means GIM told us GIM will start do FLR The later one
> > means GIM told us GIM already finished FLR and from that on Guest
> > driver can do re-initialize .
> >
> > You only handle the first IRQ, and dispatch a delay_work to monitor
> > event of IDH_FLR_NOTIFICATION_CMPL,
> >
> > I suspect that correct scheme may be you handle both of those two type
> > of IRQ , please check with @Frank and me on the detail tomorrow .
> 
> As I think we may suspend gpu after receive FLR interrupt, polling method is
> safer.
> 
> >
> > BR Monk
> >
> > -Original Message-
> > From: Xiangliang Yu [mailto:xiangliang...@amd.com]
> > Sent: Wednesday, January 11, 2017 9:18 PM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Yu, Xiangliang <xiangliang...@amd.com>; Liu, Monk
> > <monk@amd.com>; Liu, Shaoyun <shaoyun@amd.com>
> > Subject: [V3 06/11] drm/amdgpu/virt: implement VI virt operation
> > interfaces
> >
> > VI has asic specific virt support, which including mailbox and golden
> > registers init.
> >
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > Signed-off-by: Monk Liu <monk@amd.com>
> > Signed-off-by: shaoyunl <shaoyun@amd.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/Makefile  |   2 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |   9 +-
> >  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c| 592
> > +++
> >  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h|  55 +++
> >  4 files changed, 654 insertions(+), 4 deletions(-)  create mode
> > 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> >  create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> > b/drivers/gpu/drm/amd/amdgpu/Makefile
> > index 0b8e470..388e7b0 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> > @@ -40,7 +40,7 @@ amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o
> cik_ih.o
> > kv_smc.o kv_dpm.o \  amdgpu-$(CONFIG_DRM_AMDGPU_SI)+= si.o
> gmc_v6_0.o
> > gfx_v6_0.o si_ih.o si_dma.o dce_v6_0.o si_dpm.o si_smc.o
> >
> >  amdgpu-y += \
> > -   vi.o
> > +   vi.o mxgpu_vi.o
> >
> >  # add GMC block
> >  amdgpu-y += \
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > index 45771b0..a409eec 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > @@ -41,9 +41,12 @@ struct amdgpu_virt_ops {
> >
> >  /* GPU virtualization */
> >  struct amdgpu_virt {
> > -   uint32_t  

RE: [V3 05/11] drm/amdgpu/virt: add high level interfaces for virt

2017-01-11 Thread Yu, Xiangliang
> -Original Message-
> From: Liu, Monk
> Sent: Wednesday, January 11, 2017 10:33 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Subject: RE: [V3 05/11] drm/amdgpu/virt: add high level interfaces for virt
> 
> See in lines
> 
> 
> -Original Message-
> From: Yu, Xiangliang
> Sent: Wednesday, January 11, 2017 10:27 PM
> To: Liu, Monk <monk@amd.com>; amd-gfx@lists.freedesktop.org
> Subject: RE: [V3 05/11] drm/amdgpu/virt: add high level interfaces for virt
> 
> > This patch is not derived from my work (amd-sriov-4.3/4.6), please
> > don't add my "signed-off-by: Monk Liu " line on it, Seems you add an
> > upper layer interface to invoke on gpu_request/release routines, And I
> > will also take role in the reviewing of it:
> >
> > +   adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> > +   return virt->ops->req_full_gpu(adev, init);
> >
> > [ml]One nitpick , you need place " adev->virt.caps &=
> > ~AMDGPU_SRIOV_CAPS_RUNTIME;" in the second line,
> 
> I think it make more clear as it is not runtime when entering full access 
> mode.
> 
> [ml] NO, you didn't get my point, you should &= ~
> AMDGPU_SRIOV_CAPS_RUNTIME *after* virt->ops->req_full_gpu(adev,
> init)

Good catch.

> 
> >
> > +   r = virt->ops->rel_full_gpu(adev, init);
> > +   adev->virt.caps |= AMDGPU_SRIOV_CAPS_RUNTIME;
> >
> > [ml] what about rel_full_gpu() failed ?  and if rel_full_gpu is
> > designed not allowed to fail then you should type it as non-return
> > function. ( I remember in my first initial implementation on rel_gpu
> > function it is is non-return
> > function)
> 
> I think it is more flexible, we can handle error according to return result.
> 
> [ML] then please handle the error accordingly, but your patch just ignore the
> return value . see it yourself

I have no time to think of the design, maybe later.

> 
> >
> >
> > +   adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> > +   return virt->ops->reset_gpu(adev);
> > +   }
> >
> > [ML] " adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME"  should be
> put
> > to the second line as well, like:
> >
> > r = virt-ops->reset_gpu(adev);
> > If (!r)
> > adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME; else
> > BUG(); /* we shouldn't fail in requesting GPU_RESET, check
> > hypervisor please */ return r;
> 
> I think we can't hang out VM so rudely, need to print out error message and
> do error handling to enhance the process later.
> 
> [ML] you still not get my point, if reset_gpu() failed. You shouldn't "&=
> ~AMDGPU_SRIOV_CAPS_RUNTIME", but you did it in prior to reset_gpu(),
> isn't it ??
> 
> >
> > BR Monk
> >
> > -Original Message-
> > From: Xiangliang Yu [mailto:xiangliang...@amd.com]
> > Sent: Wednesday, January 11, 2017 9:18 PM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Yu, Xiangliang <xiangliang...@amd.com>; Liu, Monk
> > <monk@amd.com>
> > Subject: [V3 05/11] drm/amdgpu/virt: add high level interfaces for
> > virt
> >
> > Add high level interfaces that is not relate to specific asic. So asic
> > files just need to implement the interfaces to support virtualization.
> >
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > Signed-off-by: Monk Liu <monk@amd.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 57
> > 
> > drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 14 
> >  2 files changed, 71 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > index 7861b6b..4e7df8e 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > @@ -80,3 +80,60 @@ void amdgpu_virt_kiq_wreg(struct amdgpu_device
> > *adev, uint32_t reg, uint32_t v)
> > DRM_ERROR("wait for kiq fence error: %ld.\n", r);
> > fence_put(f);
> >  }
> > +
> > +/**
> > + * amdgpu_virt_request_full_gpu() - request full gpu access
> > + * @amdgpu:amdgpu device.
> > + * @init:  is driver init time.
> > + * When start to init/fini driver, first need to request full gpu access.
> > + * Return: Zero if request success, otherwise will return error.
> > + */
> > +int amdgpu_virt_request_full_gpu(stru

RE: [V3 06/11] drm/amdgpu/virt: implement VI virt operation interfaces

2017-01-11 Thread Yu, Xiangliang
> -Original Message-
> From: Liu, Monk
> Sent: Wednesday, January 11, 2017 10:28 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Cc: Yu, Xiangliang <xiangliang...@amd.com>; Liu, Shaoyun
> <shaoyun@amd.com>
> Subject: RE: [V3 06/11] drm/amdgpu/virt: implement VI virt operation
> interfaces
> 
> +static int xgpu_vi_mailbox_rcv_irq(struct amdgpu_device *adev,
> +struct amdgpu_irq_src *source,
> +struct amdgpu_iv_entry *entry)
> +{
> + int r;
> +
> + adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> + r = xgpu_vi_mailbox_rcv_msg(adev, IDH_FLR_NOTIFICATION);
> + /* do nothing for other msg */
> + if (r)
> + return 0;
> +
> + /* TODO: need to save gfx states */
> + schedule_delayed_work(>virt.flr_work,
> +   msecs_to_jiffies(VI_MAILBOX_RESET_TIME));
> +
> + return 0;
> +}
> 
> [ML] we should be able to receive at least two type of IRQ from mailbox:
> One is FLR_NOTIFICATION and another one is
> IDH_FLR_NOTIFICATION_CMPL,
> 
> The previous one means GIM told us GIM will start do FLR The later one
> means GIM told us GIM already finished FLR and from that on Guest driver
> can do re-initialize .
> 
> You only handle the first IRQ, and dispatch a delay_work to monitor event of
> IDH_FLR_NOTIFICATION_CMPL,
> 
> I suspect that correct scheme may be you handle both of those two type of
> IRQ , please check with @Frank and me on the detail tomorrow .

As I think we may suspend gpu after receive FLR interrupt, polling method is 
safer.

> 
> BR Monk
> 
> -----Original Message-
> From: Xiangliang Yu [mailto:xiangliang...@amd.com]
> Sent: Wednesday, January 11, 2017 9:18 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang <xiangliang...@amd.com>; Liu, Monk
> <monk@amd.com>; Liu, Shaoyun <shaoyun@amd.com>
> Subject: [V3 06/11] drm/amdgpu/virt: implement VI virt operation interfaces
> 
> VI has asic specific virt support, which including mailbox and golden 
> registers
> init.
> 
> Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> Signed-off-by: Monk Liu <monk@amd.com>
> Signed-off-by: shaoyunl <shaoyun@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/Makefile  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |   9 +-
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c| 592
> +++
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h|  55 +++
>  4 files changed, 654 insertions(+), 4 deletions(-)  create mode 100644
> drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> b/drivers/gpu/drm/amd/amdgpu/Makefile
> index 0b8e470..388e7b0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> @@ -40,7 +40,7 @@ amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o
> cik_ih.o kv_smc.o kv_dpm.o \  amdgpu-$(CONFIG_DRM_AMDGPU_SI)+=
> si.o gmc_v6_0.o gfx_v6_0.o si_ih.o si_dma.o dce_v6_0.o si_dpm.o si_smc.o
> 
>  amdgpu-y += \
> - vi.o
> + vi.o mxgpu_vi.o
> 
>  # add GMC block
>  amdgpu-y += \
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> index 45771b0..a409eec 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> @@ -41,9 +41,12 @@ struct amdgpu_virt_ops {
> 
>  /* GPU virtualization */
>  struct amdgpu_virt {
> - uint32_tcaps;
> - uint32_treg_val_offs;
> - struct mutexlock;
> + uint32_tcaps;
> + uint32_treg_val_offs;
> + struct mutexlock;
> + struct amdgpu_irq_src   ack_irq;
> + struct amdgpu_irq_src   rcv_irq;
> + struct delayed_work flr_work;
>   const struct amdgpu_virt_ops*ops;
>  };
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> new file mode 100644
> index 000..d2622b6
> --- /dev/null
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -0,0 +1,592 @@
> +/*
> + * Copyright 2017 Advanced Micro Devices, Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person
> +obtaining a
> + * copy of this software and associated documentation files (the
> +"Software"),
> + * to deal in the Software without restriction, including without
> +limitation
> + * the rights to use, co

RE: [V3 05/11] drm/amdgpu/virt: add high level interfaces for virt

2017-01-11 Thread Yu, Xiangliang
> This patch is not derived from my work (amd-sriov-4.3/4.6), please don't add
> my "signed-off-by: Monk Liu " line on it, Seems you add an upper layer
> interface to invoke on gpu_request/release routines, And I will also take role
> in the reviewing of it:
> 
> + adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> + return virt->ops->req_full_gpu(adev, init);
> 
> [ml]One nitpick , you need place " adev->virt.caps &=
> ~AMDGPU_SRIOV_CAPS_RUNTIME;" in the second line,

I think it make more clear as it is not runtime when entering full access mode.

> 
> + r = virt->ops->rel_full_gpu(adev, init);
> + adev->virt.caps |= AMDGPU_SRIOV_CAPS_RUNTIME;
> 
> [ml] what about rel_full_gpu() failed ?  and if rel_full_gpu is designed not
> allowed to fail then you should type it as non-return function. ( I remember
> in my first initial implementation on rel_gpu function it is is non-return
> function)

I think it is more flexible, we can handle error according to return result.

> 
> 
> + adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> + return virt->ops->reset_gpu(adev);
> + }
> 
> [ML] " adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME"  should be
> put to the second line as well, like:
> 
> r = virt-ops->reset_gpu(adev);
> If (!r)
> adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME; else
> BUG(); /* we shouldn't fail in requesting GPU_RESET, check hypervisor
> please */ return r;

I think we can't hang out VM so rudely, need to print out error message and do 
error handling to enhance the process later.

> 
> BR Monk
> 
> -Original Message-
> From: Xiangliang Yu [mailto:xiangliang...@amd.com]
> Sent: Wednesday, January 11, 2017 9:18 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang <xiangliang...@amd.com>; Liu, Monk
> <monk@amd.com>
> Subject: [V3 05/11] drm/amdgpu/virt: add high level interfaces for virt
> 
> Add high level interfaces that is not relate to specific asic. So asic files 
> just
> need to implement the interfaces to support virtualization.
> 
> Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> Signed-off-by: Monk Liu <monk@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 57
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 14 
>  2 files changed, 71 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index 7861b6b..4e7df8e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -80,3 +80,60 @@ void amdgpu_virt_kiq_wreg(struct amdgpu_device
> *adev, uint32_t reg, uint32_t v)
>   DRM_ERROR("wait for kiq fence error: %ld.\n", r);
>   fence_put(f);
>  }
> +
> +/**
> + * amdgpu_virt_request_full_gpu() - request full gpu access
> + * @amdgpu:  amdgpu device.
> + * @init:is driver init time.
> + * When start to init/fini driver, first need to request full gpu access.
> + * Return: Zero if request success, otherwise will return error.
> + */
> +int amdgpu_virt_request_full_gpu(struct amdgpu_device *adev, bool init)
> +{
> + struct amdgpu_virt *virt = >virt;
> +
> + if (virt->ops && virt->ops->req_full_gpu) {
> + adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> + return virt->ops->req_full_gpu(adev, init);
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * amdgpu_virt_release_full_gpu() - release full gpu access
> + * @amdgpu:  amdgpu device.
> + * @init:is driver init time.
> + * When finishing driver init/fini, need to release full gpu access.
> + * Return: Zero if release success, otherwise will returen error.
> + */
> +int amdgpu_virt_release_full_gpu(struct amdgpu_device *adev, bool init)
> +{
> + struct amdgpu_virt *virt = >virt;
> + int r;
> +
> + if (virt->ops && virt->ops->rel_full_gpu) {
> + r = virt->ops->rel_full_gpu(adev, init);
> + adev->virt.caps |= AMDGPU_SRIOV_CAPS_RUNTIME;
> + return r;
> + }
> + return 0;
> +}
> +
> +/**
> + * amdgpu_virt_reset_gpu() - reset gpu
> + * @amdgpu:  amdgpu device.
> + * Send reset command to GPU hypervisor to reset GPU that VM is using
> + * Return: Zero if reset success, otherwise will return error.
> + */
> +int amdgpu_virt_reset_gpu(struct amdgpu_device *adev) {
> + struct amdgpu_virt *virt = >virt;
> +
> + if (virt->

RE: [V3 00/11] Add support AMD GPU virtualization soultion

2017-01-11 Thread Yu, Xiangliang
> Patch #7 is missing a comment that this applies during driver load/unload,
> cause that isn't obvious.

Not just only for loading/unloading, resume process will need to 
request/release full gpu access after FLR (function level reset). Later I'll 
upstream FLR patches.

> 
> With that fixed the patch is Reviewed-by: Christian König
>  as well.
> 
> Patch #10 please add the comment that this is just a temporary workaround
> to the code as well.
> 
> With that fixed the patch is also Reviewed-by: Christian König
> .
> 
> Regards,
> Christian.
> 
> Am 11.01.2017 um 14:18 schrieb Xiangliang Yu:
> > This patch series will enable AMD GPU virtualization and wires it into
> > amdgpu modules.
> >
> > Changes in V3:
> > 1. rename field name;
> > 2. remove extra fence_get()/fence_put(); 3. fixed coding style; 4.
> > update patch comment;
> >
> > Changes in V2:
> > 1. define new high level interface for non-asic specific; 2. add asic
> > specific file to support specific asic; 3. not include KIQ patch as it
> > has been merged into kernel; 4. not include CSA patch as monk will
> > submit it;
> >
> > Xiangliang Yu (11):
> >drm/amdgpu/ring: add two interfaces to support r/w registers with kiq
> >drm/amdgpu/gfx8: implement emit_rreg/wreg function
> >drm/amdgpu/virt: add runtime flag
> >drm/amdgpu/virt: use kiq to access registers
> >drm/amdgpu/virt: add high level interfaces for virt
> >drm/amdgpu/virt: implement VI virt operation interfaces
> >drm/amdgpu: request/release full gpu access if device is vf
> >drm/amdgpu/vi: add support virtualization
> >drm/amdgpu/virt: enable virtual display
> >drm/amdgpu/virt: disable dc
> >drm/amdgpu: do not reset gpu for virtualization
> >
> >   drivers/gpu/drm/amd/amdgpu/Makefile|   4 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu.h|   2 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  21 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   6 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |   2 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c   | 146 +++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h   |  30 +-
> >   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  37 ++
> >   drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c  | 592
> +
> >   drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h  |  55 +++
> >   drivers/gpu/drm/amd/amdgpu/vi.c|  35 +-
> >   11 files changed, 926 insertions(+), 4 deletions(-)
> >   create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >   create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> >   create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> >

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


RE: [V2 02/11] drm/amdgpu/gfx8: implement emit_rreg/wreg function

2017-01-10 Thread Yu, Xiangliang
> -Original Message-
> From: Deucher, Alexander
> Sent: Tuesday, January 10, 2017 11:35 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Cc: Yu, Xiangliang <xiangliang...@amd.com>
> Subject: RE: [V2 02/11] drm/amdgpu/gfx8: implement emit_rreg/wreg
> function
> 
> > -Original Message-
> > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Xiangliang Yu
> > Sent: Tuesday, January 10, 2017 5:01 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Yu, Xiangliang
> > Subject: [V2 02/11] drm/amdgpu/gfx8: implement emit_rreg/wreg
> function
> >
> > Implement emit_rreg/wreg function for kiq ring.
> >
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |  3 ++-
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 37
> > 
> >  2 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > index 0d821d9..a6524bb 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > @@ -30,7 +30,8 @@
> >  #define AMDGPU_PASSTHROUGH_MODE(1 << 3) /* thw whole GPU
> is
> > pass through for VM */
> >  /* GPU virtualization */
> >  struct amdgpu_virt {
> > -   uint32_t caps;
> > +   uint32_tcaps;
> > +   uint32_tval_offs;
> 
> Maybe rename val_offs to register_val_offs to make it clearer what it is used
> for.  With that change, the patch is:
> Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

Ok. I'll fix it and send out V3 tomorrow.

> 
> >  };
> >
> >  #define amdgpu_sriov_enabled(adev) \
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > index b487b97..e619f49 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > @@ -1373,6 +1373,12 @@ static int gfx_v8_0_kiq_init_ring(struct
> > amdgpu_device *adev,  {
> > int r = 0;
> >
> > +   if (amdgpu_sriov_vf(adev)) {
> > +   r = amdgpu_wb_get(adev, >virt.val_offs);
> > +   if (r)
> > +   return r;
> > +   }
> > +
> > ring->adev = NULL;
> > ring->ring_obj = NULL;
> > ring->use_doorbell = true;
> > @@ -1399,6 +1405,9 @@ static int gfx_v8_0_kiq_init_ring(struct
> > amdgpu_device *adev,  static void gfx_v8_0_kiq_free_ring(struct
> > amdgpu_ring *ring,
> >struct amdgpu_irq_src *irq)
> >  {
> > +   if (amdgpu_sriov_vf(ring->adev))
> > +   amdgpu_wb_free(ring->adev, ring->adev->virt.val_offs);
> > +
> > amdgpu_ring_fini(ring);
> > irq->data = NULL;
> >  }
> > @@ -6681,6 +6690,32 @@ static void gfx_v8_ring_emit_cntxcntl(struct
> > amdgpu_ring *ring, uint32_t flags)
> > amdgpu_ring_write(ring, 0);
> >  }
> >
> > +static void gfx_v8_0_ring_emit_rreg(struct amdgpu_ring *ring,
> > +uint32_t
> > reg)
> > +{
> > +   struct amdgpu_device *adev = ring->adev;
> > +
> > +   amdgpu_ring_write(ring, PACKET3(PACKET3_COPY_DATA, 4));
> > +   amdgpu_ring_write(ring, 0 | /* src: register*/
> > +   (5 << 8) |  /* dst: memory */
> > +   (1 << 20)); /* write confirm */
> > +   amdgpu_ring_write(ring, reg);
> > +   amdgpu_ring_write(ring, 0);
> > +   amdgpu_ring_write(ring, lower_32_bits(adev->wb.gpu_addr +
> > +   adev->virt.val_offs * 4));
> > +   amdgpu_ring_write(ring, upper_32_bits(adev->wb.gpu_addr +
> > +   adev->virt.val_offs * 4));
> > +}
> > +
> > +static void gfx_v8_0_ring_emit_wreg(struct amdgpu_ring *ring,
> > +uint32_t
> > reg,
> > + uint32_t val)
> > +{
> > +   amdgpu_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
> > +   amdgpu_ring_write(ring, (1 << 16)); /* no inc addr */
> > +   amdgpu_ring_write(ring, reg);
> > +   amdgpu_ring_write(ring, 0);
> > +   amdgpu_ring_write(ring, val);
> > +}
> > +
> >  static void gfx_v8_0_set_gfx_eop_interrupt_state(struct amdgpu_device
> > *adev,
> >  enum
> > amdgpu_interrupt_state state)
> >  {
> > @@ -6995,6 +7030,8 @@ static const struct amdgpu_ring_funcs
> > gfx_v8_0_ring_funcs_kiq = {
> > .test_ib = gfx_v8_0_ring_test_ib,
> > .insert_nop = amdgpu_ring_insert_nop,
> > .pad_ib = amdgpu_ring_generic_pad_ib,
> > +   .emit_rreg = gfx_v8_0_ring_emit_rreg,
> > +   .emit_wreg = gfx_v8_0_ring_emit_wreg,
> >  };
> >
> >  static void gfx_v8_0_set_ring_funcs(struct amdgpu_device *adev)
> > --
> > 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: [V2 05/11] drm/amdgpu/virt: add high level interfaces for virt

2017-01-10 Thread Yu, Xiangliang
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Tuesday, January 10, 2017 9:59 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Subject: Re: [V2 05/11] drm/amdgpu/virt: add high level interfaces for virt
> 
> Am 10.01.2017 um 14:33 schrieb Yu, Xiangliang:
> >> -Original Message-
> >> From: Christian König [mailto:deathsim...@vodafone.de]
> >> Sent: Tuesday, January 10, 2017 9:12 PM
> >> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [V2 05/11] drm/amdgpu/virt: add high level interfaces
> >> for virt
> >>
> >> Am 10.01.2017 um 11:00 schrieb Xiangliang Yu:
> >>> Add high level interfaces that is not relate to specific asic. So
> >>> asic files just need to implement the interfaces to support 
> >>> virtualization.
> >>>
> >>> Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 57
> >> 
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 15 +
> >>>2 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 6520a4e..f32a789 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >>> @@ -84,3 +84,60 @@ void amdgpu_virt_kiq_wreg(struct
> amdgpu_device
> >> *adev, uint32_t reg, uint32_t v)
> >>>   DRM_ERROR("wait for kiq fence error: %ld.\n", r);
> >>>   fence_put(f);
> >>>}
> >>> +
> >>> +/**
> >>> + * amdgpu_virt_request_full_gpu() - request full gpu access
> >>> + * @amdgpu:  amdgpu device.
> >>> + * @init:is driver init time.
> >>> + * When start to init/fini driver, first need to request full gpu access.
> >>> + * Return: Zero if request success, otherwise will return error.
> >>> + */
> >>> +int amdgpu_virt_request_full_gpu(struct amdgpu_device *adev, bool
> >>> +init) {
> >>> + struct amdgpu_virt *virt = >virt;
> >>> +
> >>> + if (virt->ops && virt->ops->req_full_gpu) {
> >>> + adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
> >>> + return virt->ops->req_full_gpu(adev, init);
> >> I would be conservative here and request full GPU access first and
> >> then clear AMDGPU_SRIOV_CAPS_RUNTIME.
> >>
> >> Just in case the function is called concurrently with another thread
> >> checking the caps.
> > It can't be used in parallel, the problem you said shouldn't be appear.
> >
> >> On the other hand req_full_gpu() could need the flag to handle
> >> register reads/writes correctly, but in this case I would question if
> >> we shouldn't add special macros for this.
> > We must clear RUNTIME flag so that can read/write registers with mmio,
> > Otherwise driver will hang.
> 
> Yeah, that's what I expected. Would be nice if we could better split that, 
> e.g.
> have explicit macros for direct register write.
> 
> But that's really only nice to have, patch is ok as it is as far as I can see.

I think it is also very clear. Actually, I have a try but it is not good choice.
If anyone have good idea, can change it later.

> >
> >>
> >>
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +/**
> >>> + * amdgpu_virt_release_full_gpu() - release full gpu access
> >>> + * @amdgpu:  amdgpu device.
> >>> + * @init:is driver init time.
> >>> + * When finishing driver init/fini, need to release full gpu access.
> >>> + * Return: Zero if release success, otherwise will returen error.
> >>> + */
> >>> +int amdgpu_virt_release_full_gpu(struct amdgpu_device *adev, bool
> >>> +init) {
> >>> + struct amdgpu_virt *virt = >virt;
> >>> + int r;
> >>> +
> >>> + if (virt->ops && virt->ops->rel_full_gpu) {
> >>> + r = virt->ops->rel_full_gpu(adev, init);
> >>> + adev->virt.caps |= AMDGPU_SRIOV_CAPS_RUNTIME;
> >>> + return r;
> &g

RE: [V2 06/11] drm/amdgpu/virt: implement VI virt operation interfaces

2017-01-10 Thread Yu, Xiangliang
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Tuesday, January 10, 2017 10:06 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Subject: Re: [V2 06/11] drm/amdgpu/virt: implement VI virt operation
> interfaces
> 
> Am 10.01.2017 um 14:43 schrieb Yu, Xiangliang:
> >> -Original Message-
> >> From: Christian König [mailto:deathsim...@vodafone.de]
> >> Sent: Tuesday, January 10, 2017 9:30 PM
> >> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [V2 06/11] drm/amdgpu/virt: implement VI virt operation
> >> interfaces
> >>
> >> Am 10.01.2017 um 14:20 schrieb Yu, Xiangliang:
> >>>> -Original Message-
> >>>> From: Christian König [mailto:deathsim...@vodafone.de]
> >>>> Sent: Tuesday, January 10, 2017 9:16 PM
> >>>> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> >>>> g...@lists.freedesktop.org
> >>>> Subject: Re: [V2 06/11] drm/amdgpu/virt: implement VI virt
> >>>> operation interfaces
> >>>>
> >>>> Unrelated to the patch, but what editor and settings do you use?
> >>> Vim
> >> dito.
> >>
> >>>> See this code for example
> >>>>> +   reg = REG_SET_FIELD(reg, MAILBOX_CONTROL,
> >>>>> +TRN_MSG_VALID, val ? 1 : 0);
> >>>> The indentation seems to be incorrect.
> >>> In my platform, there is no problem.
> >> Are you using linuxsty.vim or something else?
> > No, I configure it by myself.
> 
> Ah, there it comes from. Please use linuxsty.vim or any other predefined set
> of setting for vim.
> 
> Configuring it yourself is usually not a good idea, cause that can easily 
> lead to
> slightly different coding styles.

All right

> 
> >
> >> If I'm not completely mistaken "TRN_MSG_VALID" should be on the same
> >> indentation as "reg" and not as "MAILBOX_CONTROL".
> > I think it should be on same as "MAILBOX_CONTROL" as it is also macro and
> capital.
> 
> No, function arguments broken to the next line should start at the same
> place as the "(" of the previous line.
> 
> See the other code in amdgpu as well or just use linuxsty.

Got it. I'll also check other code later

> 
> Regards,
> Christian.
> 
> >
> >>>> Not much of a problem, but if we add this like it is anybody else
> >>>> editing the file could mess up the indentation when the editor does
> that
> >> differently.
> >>>> Regards,
> >>>> Christian.
> >>>>
> >>>> Am 10.01.2017 um 11:00 schrieb Xiangliang Yu:
> >>>>> VI has asic specific virt support, which including mailbox and
> >>>>> golden registers init.
> >>>>>
> >>>>> Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> >>>>> ---
> >>>>> drivers/gpu/drm/amd/amdgpu/Makefile  |   2 +-
> >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |   3 +
> >>>>> drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c| 592
> >>>> +++
> >>>>> drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h|  55 +++
> >>>>> 4 files changed, 651 insertions(+), 1 deletion(-)
> >>>>> create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> >>>>> create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> >>>>> b/drivers/gpu/drm/amd/amdgpu/Makefile
> >>>>> index 0b8e470..388e7b0 100644
> >>>>> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> >>>>> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> >>>>> @@ -40,7 +40,7 @@ amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+=
> cik.o
> >>>> cik_ih.o kv_smc.o kv_dpm.o \
> >>>>> amdgpu-$(CONFIG_DRM_AMDGPU_SI)+= si.o gmc_v6_0.o
> gfx_v6_0.o
> >>>> si_ih.o
> >>>>> si_dma.o dce_v6_0.o si_dpm.o si_smc.o
> >>>>>
> >>>>> amdgpu-y += \
> >>>>> -   vi.o
> >>>>> +   vi.o mxgpu_vi.o
> >>>>>
> >>>>> # add GMC block
> >>>>> amdgpu-y += \
> >>>>> dif

RE: [V2 04/11] drm/amdgpu/virt: use kiq to access registers

2017-01-10 Thread Yu, Xiangliang
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Tuesday, January 10, 2017 10:08 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Subject: Re: [V2 04/11] drm/amdgpu/virt: use kiq to access registers
> 
> Am 10.01.2017 um 15:01 schrieb Yu, Xiangliang:
> >> -Original Message-
> >> From: Christian König [mailto:deathsim...@vodafone.de]
> >> Sent: Tuesday, January 10, 2017 9:09 PM
> >> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [V2 04/11] drm/amdgpu/virt: use kiq to access registers
> >>
> >> Am 10.01.2017 um 11:00 schrieb Xiangliang Yu:
> >>> For virtualization, it is must for driver to use KIQ to access
> >>> registers when it is out of GPU full access mode.
> >>>
> >>> Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/Makefile|  2 +-
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  6 +++
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c   | 86
> >> ++
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h   |  5 ++
> >>>drivers/gpu/drm/amd/amdgpu/vi.c|  3 ++
> >>>5 files changed, 101 insertions(+), 1 deletion(-)
> >>>create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> b/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> index 4185b03..0b8e470 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> @@ -30,7 +30,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
> >>>   atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
> >>>   amdgpu_prime.o amdgpu_vm.o amdgpu_ib.o amdgpu_pll.o \
> >>>   amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
> >>> - amdgpu_gtt_mgr.o amdgpu_vram_mgr.o
> >>> + amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o
> >>>
> >>># add asic specific block
> >>>amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o
> >> kv_dpm.o \
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> index f82919d..9a2fd3e 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> @@ -95,6 +95,9 @@ uint32_t amdgpu_mm_rreg(struct amdgpu_device
> >> *adev, uint32_t reg,
> >>>{
> >>>   uint32_t ret;
> >>>
> >>> + if (amdgpu_sriov_runtime(adev) && !in_interrupt())
> >>> + return amdgpu_virt_kiq_rreg(adev, reg);
> >>> +
> >>>   if ((reg * 4) < adev->rmmio_size && !always_indirect)
> >>>   ret = readl(((void __iomem *)adev->rmmio) + (reg * 4));
> >>>   else {
> >>> @@ -114,6 +117,9 @@ void amdgpu_mm_wreg(struct amdgpu_device
> >> *adev, uint32_t reg, uint32_t v,
> >>>{
> >>>   trace_amdgpu_mm_wreg(adev->pdev->device, reg, v);
> >>>
> >>> + if (amdgpu_sriov_runtime(adev))
> >>> + return amdgpu_virt_kiq_wreg(adev, reg, v);
> >>> +
> >>>   if ((reg * 4) < adev->rmmio_size && !always_indirect)
> >>>   writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
> >>>   else {
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >>> new file mode 100644
> >>> index 000..6520a4e
> >>> --- /dev/null
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >>> @@ -0,0 +1,86 @@
> >>> +/*
> >>> + * Copyright 2017 Advanced Micro Devices, Inc.
> >>> + *
> >>> + * Permission is hereby granted, free of charge, to any person
> >>> +obtaining a
> >>> + * copy of this software and associated documentation files (the
> >>> +"Software"),
> >>> + * to deal in the Software without restriction, including without
> >>> +limitation
> >>> + * the rights to use, copy, modify, merge, publish, distribute,
> >>&g

RE: [V2 04/11] drm/amdgpu/virt: use kiq to access registers

2017-01-10 Thread Yu, Xiangliang
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Tuesday, January 10, 2017 9:09 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Subject: Re: [V2 04/11] drm/amdgpu/virt: use kiq to access registers
> 
> Am 10.01.2017 um 11:00 schrieb Xiangliang Yu:
> > For virtualization, it is must for driver to use KIQ to access
> > registers when it is out of GPU full access mode.
> >
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/Makefile|  2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  6 +++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c   | 86
> ++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h   |  5 ++
> >   drivers/gpu/drm/amd/amdgpu/vi.c|  3 ++
> >   5 files changed, 101 insertions(+), 1 deletion(-)
> >   create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> > b/drivers/gpu/drm/amd/amdgpu/Makefile
> > index 4185b03..0b8e470 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> > @@ -30,7 +30,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
> > atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
> > amdgpu_prime.o amdgpu_vm.o amdgpu_ib.o amdgpu_pll.o \
> > amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
> > -   amdgpu_gtt_mgr.o amdgpu_vram_mgr.o
> > +   amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o
> >
> >   # add asic specific block
> >   amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o
> kv_dpm.o \
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index f82919d..9a2fd3e 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -95,6 +95,9 @@ uint32_t amdgpu_mm_rreg(struct amdgpu_device
> *adev, uint32_t reg,
> >   {
> > uint32_t ret;
> >
> > +   if (amdgpu_sriov_runtime(adev) && !in_interrupt())
> > +   return amdgpu_virt_kiq_rreg(adev, reg);
> > +
> > if ((reg * 4) < adev->rmmio_size && !always_indirect)
> > ret = readl(((void __iomem *)adev->rmmio) + (reg * 4));
> > else {
> > @@ -114,6 +117,9 @@ void amdgpu_mm_wreg(struct amdgpu_device
> *adev, uint32_t reg, uint32_t v,
> >   {
> > trace_amdgpu_mm_wreg(adev->pdev->device, reg, v);
> >
> > +   if (amdgpu_sriov_runtime(adev))
> > +   return amdgpu_virt_kiq_wreg(adev, reg, v);
> > +
> > if ((reg * 4) < adev->rmmio_size && !always_indirect)
> > writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
> > else {
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > new file mode 100644
> > index 000..6520a4e
> > --- /dev/null
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > @@ -0,0 +1,86 @@
> > +/*
> > + * Copyright 2017 Advanced Micro Devices, Inc.
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > +obtaining a
> > + * copy of this software and associated documentation files (the
> > +"Software"),
> > + * to deal in the Software without restriction, including without
> > +limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > +sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom
> > +the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > +included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> > +EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > +MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN
> NO EVENT
> > +SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> > +DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> > +OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
> THE USE
> > +OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +#include "amdgpu.h

RE: [V2 06/11] drm/amdgpu/virt: implement VI virt operation interfaces

2017-01-10 Thread Yu, Xiangliang
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Tuesday, January 10, 2017 9:30 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Subject: Re: [V2 06/11] drm/amdgpu/virt: implement VI virt operation
> interfaces
> 
> Am 10.01.2017 um 14:20 schrieb Yu, Xiangliang:
> >> -Original Message-
> >> From: Christian König [mailto:deathsim...@vodafone.de]
> >> Sent: Tuesday, January 10, 2017 9:16 PM
> >> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [V2 06/11] drm/amdgpu/virt: implement VI virt operation
> >> interfaces
> >>
> >> Unrelated to the patch, but what editor and settings do you use?
> > Vim
> 
> dito.
> 
> >
> >> See this code for example
> >>> + reg = REG_SET_FIELD(reg, MAILBOX_CONTROL,
> >>> +  TRN_MSG_VALID, val ? 1 : 0);
> >> The indentation seems to be incorrect.
> > In my platform, there is no problem.
> 
> Are you using linuxsty.vim or something else?

No, I configure it by myself. 

> 
> If I'm not completely mistaken "TRN_MSG_VALID" should be on the same
> indentation as "reg" and not as "MAILBOX_CONTROL".

I think it should be on same as "MAILBOX_CONTROL" as it is also macro and 
capital.

> >
> >> Not much of a problem, but if we add this like it is anybody else
> >> editing the file could mess up the indentation when the editor does that
> differently.
> >>
> >> Regards,
> >> Christian.
> >>
> >> Am 10.01.2017 um 11:00 schrieb Xiangliang Yu:
> >>> VI has asic specific virt support, which including mailbox and
> >>> golden registers init.
> >>>
> >>> Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/Makefile  |   2 +-
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |   3 +
> >>>drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c| 592
> >> +++
> >>>drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h|  55 +++
> >>>4 files changed, 651 insertions(+), 1 deletion(-)
> >>>create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> >>>create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> b/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> index 0b8e470..388e7b0 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> @@ -40,7 +40,7 @@ amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o
> >> cik_ih.o kv_smc.o kv_dpm.o \
> >>>amdgpu-$(CONFIG_DRM_AMDGPU_SI)+= si.o gmc_v6_0.o gfx_v6_0.o
> >> si_ih.o
> >>> si_dma.o dce_v6_0.o si_dpm.o si_smc.o
> >>>
> >>>amdgpu-y += \
> >>> - vi.o
> >>> + vi.o mxgpu_vi.o
> >>>
> >>># add GMC block
> >>>amdgpu-y += \
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> >>> index 3f8fc0f..611676b 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> >>> @@ -45,6 +45,9 @@ struct amdgpu_virt {
> >>>   uint32_tval_offs;
> >>>   struct mutexlock;
> >>>
> >>> + struct amdgpu_irq_src   ack_irq;
> >>> + struct amdgpu_irq_src   rcv_irq;
> >>> + struct delayed_work flr_work;
> >>>   const struct amdgpu_virt_ops*ops;
> >>>};
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> >>> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> >>> new file mode 100644
> >>> index 000..7d44663
> >>> --- /dev/null
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> >>> @@ -0,0 +1,592 @@
> >>> +/*
> >>> + * Copyright 2017 Advanced Micro Devices, Inc.
> >>> + *
> >>> + * Permission is hereby granted, free of charge, to any person
> >>> +obtaining a
> >>> + * copy of this software and associated documentation files (the
> >>> +"Software"),
> >>> + * to deal in the Software without restriction, incl

RE: [V2 11/11] drm/amdgpu: do not reset gpu for virtualization

2017-01-10 Thread Yu, Xiangliang
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Tuesday, January 10, 2017 9:19 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: Re: [V2 11/11] drm/amdgpu: do not reset gpu for virtualization
> 
> Am 10.01.2017 um 11:00 schrieb Xiangliang Yu:
> > Current job timeout setting is not fit for virtualization, so it will
> > cause job timeout sometimes. Add workaround for this when timeout
> > happen.
> >
> > Signed-off-by: Monk Liu <monk@amd.com>
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index a6d828c..5705fbd 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -2324,6 +2324,9 @@ int amdgpu_gpu_reset(struct amdgpu_device
> *adev)
> > int resched;
> > bool need_full_reset;
> >
> > +   if (amdgpu_sriov_vf(adev))
> 
> At bare minimum we should print a warning here and increase or completely
> disable the job timeout when virtualization is enabled.

The timeout function has the warning message, I think don't need more.
The patch is just a workaround, later need to enhance the whole gpu reset 
process.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [V2 06/11] drm/amdgpu/virt: implement VI virt operation interfaces

2017-01-10 Thread Yu, Xiangliang
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Tuesday, January 10, 2017 9:16 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Subject: Re: [V2 06/11] drm/amdgpu/virt: implement VI virt operation
> interfaces
> 
> Unrelated to the patch, but what editor and settings do you use?

Vim

> 
> See this code for example
> > +   reg = REG_SET_FIELD(reg, MAILBOX_CONTROL,
> > +TRN_MSG_VALID, val ? 1 : 0);
> 
> The indentation seems to be incorrect.

In my platform, there is no problem. 

> 
> Not much of a problem, but if we add this like it is anybody else editing the
> file could mess up the indentation when the editor does that differently.
> 
> Regards,
> Christian.
> 
> Am 10.01.2017 um 11:00 schrieb Xiangliang Yu:
> > VI has asic specific virt support, which including mailbox and golden
> > registers init.
> >
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/Makefile  |   2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |   3 +
> >   drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c| 592
> +++
> >   drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h|  55 +++
> >   4 files changed, 651 insertions(+), 1 deletion(-)
> >   create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> >   create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.h
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> > b/drivers/gpu/drm/amd/amdgpu/Makefile
> > index 0b8e470..388e7b0 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> > @@ -40,7 +40,7 @@ amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o
> cik_ih.o kv_smc.o kv_dpm.o \
> >   amdgpu-$(CONFIG_DRM_AMDGPU_SI)+= si.o gmc_v6_0.o gfx_v6_0.o
> si_ih.o
> > si_dma.o dce_v6_0.o si_dpm.o si_smc.o
> >
> >   amdgpu-y += \
> > -   vi.o
> > +   vi.o mxgpu_vi.o
> >
> >   # add GMC block
> >   amdgpu-y += \
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > index 3f8fc0f..611676b 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > @@ -45,6 +45,9 @@ struct amdgpu_virt {
> > uint32_tval_offs;
> > struct mutexlock;
> >
> > +   struct amdgpu_irq_src   ack_irq;
> > +   struct amdgpu_irq_src   rcv_irq;
> > +   struct delayed_work flr_work;
> > const struct amdgpu_virt_ops*ops;
> >   };
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > new file mode 100644
> > index 000..7d44663
> > --- /dev/null
> > +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > @@ -0,0 +1,592 @@
> > +/*
> > + * Copyright 2017 Advanced Micro Devices, Inc.
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > +obtaining a
> > + * copy of this software and associated documentation files (the
> > +"Software"),
> > + * to deal in the Software without restriction, including without
> > +limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > +sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom
> > +the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > +included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> > +EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > +MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN
> NO EVENT
> > +SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> > +DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> > +OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
> THE USE
> > +OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + *
> > + * Authors: xiangliang...@amd.com
> > + */
> > +
> > +#include "amdgpu.h"
> > +#include "vi.h"
> > +#include "bif/bif_5_0_d.h"
> > +#include "bif/bif_5_0_sh_mask.h"
> > +#include "vid.

RE: [PATCH 2/2] drm/amdgpu: remove detect_hw_virtualization interface

2017-01-08 Thread Yu, Xiangliang

>From: Liu, Monk 
>Sent: Monday, January 09, 2017 11:32 AM
>To: Yu, Xiangliang <xiangliang...@amd.com>; amd-gfx@lists.freedesktop.org
>Subject: 答复: [PATCH 2/2] drm/amdgpu: remove detect_hw_virtualization interface

>after you removed this interface, don't forget to call thos 
>"xx_detect_hw_virtualization" in head of xx_set_ip_blocks() routine

>e.g. CI also need its "adev->virt.caps" with flag of "AMDGPU_PASSTHROUGH_MODE"

Sure.

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


RE: [PATCH 1/2] drm/amdgpu/vi: move virtualization detection forward

2017-01-08 Thread Yu, Xiangliang

>please change as below accordingly:
> 1, call "vi_detect_hw_virtualization" in vi_set_ip_blocks directly 

That is what my patch does

>2, drop below changes:
>+   if (amdgpu_sriov_vf(adev)) {
>+   amdgpu_ip_block_add(adev, _common_ip_block);
>+   amdgpu_ip_block_add(adev, _v8_5_ip_block);
>+   amdgpu_ip_block_add(adev, _ih_ip_block);
>+   amdgpu_ip_block_add(adev, _pp_ip_block);
>+   amdgpu_ip_block_add(adev, _virtual_ip_block);
>+   amdgpu_ip_block_add(adev, _v8_0_ip_block);
>+   amdgpu_ip_block_add(adev, _v3_0_ip_block);
>+   }

>since some ip  version is different between VI (e.g. FIJI use gmc_v8_5 and 
>tonga use v8_0, so your change at last increase more lines, we'll finally 
>support TONGA/FIJI/Ellesmere for SRIOV)

Make sense. I'll send out v2 to change it.

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


RE: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface queue(KIQ)

2017-01-04 Thread Yu, Xiangliang
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Wednesday, January 04, 2017 10:13 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; Zhou, David(ChunMing)
> <david1.z...@amd.com>; amd-gfx@lists.freedesktop.org; Liu, Monk
> <monk@amd.com>
> Subject: Re: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface
> queue(KIQ)
> 
> Am 04.01.2017 um 14:26 schrieb Yu, Xiangliang:
> >>>> Am 28.12.2016 um 03:59 schrieb Yu, Xiangliang:
> >>>>>> -Original Message-
> >>>>>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On
> >>>>>> Behalf Of zhoucm1
> >>>>>> Sent: Wednesday, December 28, 2016 10:32 AM
> >>>>>> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> >>>>>> g...@lists.freedesktop.org
> >>>>>> Cc: Liu, Monk <monk@amd.com>
> >>>>>> Subject: Re: [V2 1/1] drm/amdgpu/gfx8: add support kernel
> >>>>>> interface
> >>>>>> queue(KIQ)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 2016年12月28日 10:27, Yu, Xiangliang wrote:
> >>>>>>> +
> >>>>>>>> +amdgpu_bo_kunmap(kiq->eop_obj);
> >>>>>>>> +
> >>>>>> I see it is in many places, which is don't need I think,
> >>>>>> amdgpu_bo_free_kernel will handle it if I'm correct.
> >>>>> Memory kmap should be free ASAP from memory management point.
> >>>> No, that is completely unnecessary as long as you don't run a 32bit
> >>>> system with tight address space.
> >>> We can't decide what OS to use.  I agree with monk's comment that
> >>> better
> >> to unmap it if cpu don't use.
> >>
> >> No it isn't. As I said this is only necessary on 32bit systems with
> >> tight address space. In other words we simply don't really support
> >> that configuration any more.
> >>
> >> If you don't need it then why do you want to kmap it in the first place?
> >>
> > In my patch, first get mqd address to fill out mqd context through kmap,
> then setup compute queue with kiq ring.
> >
> > And I see there are lot of similar usage in amdgpu, for example,
> gfx_v8_0_rlc_init function. Could you help to explain it?
> 
> Ah! So you only map it initially to fill in some data structure during
> initialization? Yeah, in this case just map the BO temporary, fill in the 
> data and
> unmap it again.

Yes.

> 
> Sorry, judging from the comments I thought that you map/unmap the BO
> multiple times on each IOCTL. That is really something we should try to avoid.
> 
> Just make sure that you don't store the pointer returned by kmap anywhere,
> it is only valid temporarily.

Got it. Thanks!
 

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


RE: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface queue(KIQ)

2017-01-01 Thread Yu, Xiangliang
> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: Saturday, December 31, 2016 2:54 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>; Liu, Monk
> <monk@amd.com>
> Subject: Re: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface
> queue(KIQ)
> 
> On Fri, Dec 23, 2016 at 2:08 AM, Xiangliang Yu <xiangliang...@amd.com>
> wrote:
> > KIQ is queue-memory based initialization method: setup KIQ queue
> > firstly, then send command to KIQ to setup other queues, without
> > accessing registers.
> >
> > For virtualization, need KIQ to access virtual function registers when
> > running on guest mode.
> >
> > changes in v2:
> > 1. use amdgpu_bo_create/free_kernel to allocate OB.
> >
> > Signed-off-by: Monk Liu <monk@amd.com>
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  13 +
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 607
> +-
> >  drivers/gpu/drm/amd/amdgpu/vid.h  |   2 +
> >  3 files changed, 620 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index 9ea5bf0..c392882 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -186,6 +186,11 @@ enum amdgpu_thermal_irq {
> > AMDGPU_THERMAL_IRQ_LAST
> >  };
> >
> > +enum amdgpu_kiq_irq {
> > +   AMDGPU_CP_KIQ_IRQ_DRIVER0 = 0,
> > +   AMDGPU_CP_KIQ_IRQ_LAST
> > +};
> 
> Is there a reason to make this a separate enum rather than just adding it to
> amdgpu_cp_irq?
> 
> > +
> >  int amdgpu_set_clockgating_state(struct amdgpu_device *adev,
> >   enum amd_ip_block_type block_type,
> >   enum amd_clockgating_state state);
> > @@ -778,6 +783,13 @@ struct amdgpu_mec {
> > u32 num_queue;
> >  };
> >
> > +struct amdgpu_kiq {
> > +   u64 eop_gpu_addr;
> > +   struct amdgpu_bo*eop_obj;
> > +   struct amdgpu_ring  ring;
> > +   struct amdgpu_irq_src   irq;
> > +};
> > +
> >  /*
> >   * GPU scratch registers structures, functions & helpers
> >   */
> > @@ -853,6 +865,7 @@ struct amdgpu_gfx {
> > struct amdgpu_gca_configconfig;
> > struct amdgpu_rlc   rlc;
> > struct amdgpu_mec   mec;
> > +   struct amdgpu_kiq   kiq;
> > struct amdgpu_scratch   scratch;
> > const struct firmware   *me_fw; /* ME firmware */
> > uint32_tme_fw_version;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > index c3e6bfc..a233eeb 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > @@ -1367,6 +1367,42 @@ static void gfx_v8_0_mec_fini(struct
> amdgpu_device *adev)
> > }
> >  }
> >
> > +static int gfx_v8_0_kiq_init_ring(struct amdgpu_device *adev,
> > + struct amdgpu_ring *ring,
> > + struct amdgpu_irq_src *irq) {
> > +   int r = 0;
> > +
> > +   ring->adev = NULL;
> > +   ring->ring_obj = NULL;
> > +   ring->use_doorbell = true;
> > +   ring->doorbell_index = AMDGPU_DOORBELL_KIQ;
> > +   if (adev->gfx.mec2_fw) {
> > +   ring->me = 2;
> > +   ring->pipe = 0;
> > +   } else {
> > +   ring->me = 1;
> > +   ring->pipe = 1;
> > +   }
> > +
> > +   irq->data = ring;
> > +   ring->queue = 0;
> > +   sprintf(ring->name, "kiq %d.%d.%d", ring->me, ring->pipe, ring-
> >queue);
> > +   r = amdgpu_ring_init(adev, ring, 1024,
> > +irq, AMDGPU_CP_KIQ_IRQ_DRIVER0);
> > +   if (r)
> > +   dev_warn(adev->dev, "(%d) failed to init kiq ring\n",
> > + r);
> > +
> > +   return r;
> > +}
> > +
> > +static void gfx_v8_0_kiq_free_ring(struct amdgpu_ring *ring,
> > +  struct amdgpu_irq_src *irq) {
> > +   amdgpu_ring_fini(ring);
> > +   irq->dat

RE: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface queue(KIQ)

2016-12-27 Thread Yu, Xiangliang

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of zhoucm1
> Sent: Wednesday, December 28, 2016 10:32 AM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: Re: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface
> queue(KIQ)
> 
> 
> 
> On 2016年12月28日 10:27, Yu, Xiangliang wrote:
> > +
> > >+  amdgpu_bo_kunmap(kiq->eop_obj);
> > >+
> I see it is in many places, which is don't need I think,
> amdgpu_bo_free_kernel will handle it if I'm correct.

Memory kmap should be free ASAP from memory management point.

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


RE: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface queue(KIQ)

2016-12-27 Thread Yu, Xiangliang
Does anyone can give some comments? 
This is urgent case.


Thanks!
Xiangliang Yu

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Xiangliang Yu
> Sent: Friday, December 23, 2016 3:08 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang <xiangliang...@amd.com>; Liu, Monk
> <monk@amd.com>
> Subject: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface queue(KIQ)
> 
> KIQ is queue-memory based initialization method: setup KIQ queue firstly,
> then send command to KIQ to setup other queues, without accessing
> registers.
> 
> For virtualization, need KIQ to access virtual function registers when running
> on guest mode.
> 
> changes in v2:
> 1. use amdgpu_bo_create/free_kernel to allocate OB.
> 
> Signed-off-by: Monk Liu <monk@amd.com>
> Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  13 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 607
> +-
>  drivers/gpu/drm/amd/amdgpu/vid.h  |   2 +
>  3 files changed, 620 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 9ea5bf0..c392882 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -186,6 +186,11 @@ enum amdgpu_thermal_irq {
>   AMDGPU_THERMAL_IRQ_LAST
>  };
> 
> +enum amdgpu_kiq_irq {
> + AMDGPU_CP_KIQ_IRQ_DRIVER0 = 0,
> + AMDGPU_CP_KIQ_IRQ_LAST
> +};
> +
>  int amdgpu_set_clockgating_state(struct amdgpu_device *adev,
> enum amd_ip_block_type block_type,
> enum amd_clockgating_state state); @@ -
> 778,6 +783,13 @@ struct amdgpu_mec {
>   u32 num_queue;
>  };
> 
> +struct amdgpu_kiq {
> + u64 eop_gpu_addr;
> + struct amdgpu_bo*eop_obj;
> + struct amdgpu_ring  ring;
> + struct amdgpu_irq_src   irq;
> +};
> +
>  /*
>   * GPU scratch registers structures, functions & helpers
>   */
> @@ -853,6 +865,7 @@ struct amdgpu_gfx {
>   struct amdgpu_gca_configconfig;
>   struct amdgpu_rlc   rlc;
>   struct amdgpu_mec   mec;
> + struct amdgpu_kiq   kiq;
>   struct amdgpu_scratch   scratch;
>   const struct firmware   *me_fw; /* ME firmware */
>   uint32_tme_fw_version;
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index c3e6bfc..a233eeb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -1367,6 +1367,42 @@ static void gfx_v8_0_mec_fini(struct
> amdgpu_device *adev)
>   }
>  }
> 
> +static int gfx_v8_0_kiq_init_ring(struct amdgpu_device *adev,
> +   struct amdgpu_ring *ring,
> +   struct amdgpu_irq_src *irq)
> +{
> + int r = 0;
> +
> + ring->adev = NULL;
> + ring->ring_obj = NULL;
> + ring->use_doorbell = true;
> + ring->doorbell_index = AMDGPU_DOORBELL_KIQ;
> + if (adev->gfx.mec2_fw) {
> + ring->me = 2;
> + ring->pipe = 0;
> + } else {
> + ring->me = 1;
> + ring->pipe = 1;
> + }
> +
> + irq->data = ring;
> + ring->queue = 0;
> + sprintf(ring->name, "kiq %d.%d.%d", ring->me, ring->pipe, ring-
> >queue);
> + r = amdgpu_ring_init(adev, ring, 1024,
> +  irq, AMDGPU_CP_KIQ_IRQ_DRIVER0);
> + if (r)
> + dev_warn(adev->dev, "(%d) failed to init kiq ring\n", r);
> +
> + return r;
> +}
> +
> +static void gfx_v8_0_kiq_free_ring(struct amdgpu_ring *ring,
> +struct amdgpu_irq_src *irq)
> +{
> + amdgpu_ring_fini(ring);
> + irq->data = NULL;
> +}
> +
>  #define MEC_HPD_SIZE 2048
> 
>  static int gfx_v8_0_mec_init(struct amdgpu_device *adev) @@ -1421,6
> +1457,35 @@ static int gfx_v8_0_mec_init(struct amdgpu_device *adev)
>   return 0;
>  }
> 
> +static void gfx_v8_0_kiq_fini(struct amdgpu_device *adev) {
> + struct amdgpu_kiq *kiq = >gfx.kiq;
> +
> + amdgpu_bo_free_kernel(>eop_obj, >eop_gpu_addr,
> NULL);
> + kiq->eop_obj = NULL;
> +}
> +
> +static int gfx_v8_0_kiq_init(struct amdgpu_device *adev) {
> + int r;
> + u32 *hpd;
> + struct amdgpu_kiq *kiq = >gfx.kiq;
> +
> + r = amdgpu_bo_cr

RE: [PATCH 1/1] drm/amdgpu/gfx8: add support kernel interface queue(KIQ)

2016-12-22 Thread Yu, Xiangliang
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of zhoucm1
> Sent: Thursday, December 22, 2016 5:01 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: Re: [PATCH 1/1] drm/amdgpu/gfx8: add support kernel interface
> queue(KIQ)
> 
> 
> 
> On 2016年12月22日 16:58, Yu, Xiangliang wrote:
> >> -Original Message-
> >> From: Zhou, David(ChunMing)
> >> Sent: Tuesday, December 20, 2016 5:49 PM
> >> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> >> g...@lists.freedesktop.org
> >> Cc: Liu, Monk <monk@amd.com>
> >> Subject: Re: [PATCH 1/1] drm/amdgpu/gfx8: add support kernel
> >> interface
> >> queue(KIQ)
> >>
> >>
> >>
> >> On 2016年12月20日 17:48, Xiangliang Yu wrote:
> >>> + if (kiq->eop_obj == NULL) {
> >>> + r = amdgpu_bo_create(adev,
> >>> +  MEC_HPD_SIZE,
> >>> +  PAGE_SIZE, true,
> >>> +  AMDGPU_GEM_DOMAIN_GTT, 0, NULL,
> >> NULL,
> >>> +  >eop_obj);
> >>> + if (r) {
> >>> + dev_warn(adev->dev, "(%d) create HDP EOP bo
> >> failed\n", r);
> >>> + return r;
> >>> + }
> >>> + }
> >>> +
> >>> + r = amdgpu_bo_reserve(kiq->eop_obj, false);
> >>> + if (unlikely(r != 0)) {
> >>> + gfx_v8_0_kiq_fini(adev);
> >>> + return r;
> >>> + }
> >>> +
> >>> + r = amdgpu_bo_pin(kiq->eop_obj, AMDGPU_GEM_DOMAIN_GTT,
> >>> +   >eop_gpu_addr);
> >>> + if (r) {
> >>> + dev_warn(adev->dev, "(%d) pin HDP EOP bo failed\n", r);
> >>> + gfx_v8_0_kiq_fini(adev);
> >>> + return r;
> >>> + }
> >>> +
> >>> + r = amdgpu_bo_kmap(kiq->eop_obj, (void **));
> >> you can use amdgpu_bo_create/free_kernel helper to do these.
> > First I have same idea, but I find rlc_init & mec_init hasn't use this 
> > helper, I
> don’t know why. So just following rlc_init& mec_init behavior.
> >
> > Could you tell me why not use don’t use amdpgu_bo_create/free_kerenl
> helper in rlc_init & mec_init?
> Yeah, I realized them as well, they certainly need to use helper, which could
> be forgot by code creator. You can do that with a separate patch for it, that
> would be  fine.

Ok, thanks!

> 
> ___
> 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/1] drm/amdgpu/gfx8: add support kernel interface queue(KIQ)

2016-12-22 Thread Yu, Xiangliang
> -Original Message-
> From: Zhou, David(ChunMing)
> Sent: Tuesday, December 20, 2016 5:49 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; amd-
> g...@lists.freedesktop.org
> Cc: Liu, Monk <monk@amd.com>
> Subject: Re: [PATCH 1/1] drm/amdgpu/gfx8: add support kernel interface
> queue(KIQ)
> 
> 
> 
> On 2016年12月20日 17:48, Xiangliang Yu wrote:
> > +   if (kiq->eop_obj == NULL) {
> > +   r = amdgpu_bo_create(adev,
> > +MEC_HPD_SIZE,
> > +PAGE_SIZE, true,
> > +AMDGPU_GEM_DOMAIN_GTT, 0, NULL,
> NULL,
> > +>eop_obj);
> > +   if (r) {
> > +   dev_warn(adev->dev, "(%d) create HDP EOP bo
> failed\n", r);
> > +   return r;
> > +   }
> > +   }
> > +
> > +   r = amdgpu_bo_reserve(kiq->eop_obj, false);
> > +   if (unlikely(r != 0)) {
> > +   gfx_v8_0_kiq_fini(adev);
> > +   return r;
> > +   }
> > +
> > +   r = amdgpu_bo_pin(kiq->eop_obj, AMDGPU_GEM_DOMAIN_GTT,
> > + >eop_gpu_addr);
> > +   if (r) {
> > +   dev_warn(adev->dev, "(%d) pin HDP EOP bo failed\n", r);
> > +   gfx_v8_0_kiq_fini(adev);
> > +   return r;
> > +   }
> > +
> > +   r = amdgpu_bo_kmap(kiq->eop_obj, (void **));
> you can use amdgpu_bo_create/free_kernel helper to do these.

First I have same idea, but I find rlc_init & mec_init hasn't use this helper, 
I don’t know why. So just following rlc_init& mec_init behavior.

Could you tell me why not use don’t use amdpgu_bo_create/free_kerenl helper in 
rlc_init & mec_init?

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


RE: [PATCH 09/23] drm/amdgpu: enable virtualization feature for FIJI/TONGA

2016-12-20 Thread Yu, Xiangliang

> -Original Message-
> From: Deucher, Alexander
> Sent: Tuesday, December 20, 2016 11:53 PM
> To: Yu, Xiangliang <xiangliang...@amd.com>; Alex Deucher
> <alexdeuc...@gmail.com>
> Cc: dl.SRDC_SW_GPUVirtualization
> <dl.srdc_sw_gpuvirtualizat...@amd.com>; amd-gfx list  g...@lists.freedesktop.org>
> Subject: RE: [PATCH 09/23] drm/amdgpu: enable virtualization feature for
> FIJI/TONGA
> 
> > -Original Message-
> > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Yu, Xiangliang
> > Sent: Tuesday, December 20, 2016 12:41 AM
> > To: Alex Deucher
> > Cc: dl.SRDC_SW_GPUVirtualization; amd-gfx list
> > Subject: RE: [PATCH 09/23] drm/amdgpu: enable virtualization feature
> > for FIJI/TONGA
> >
> >
> > > -Original Message-----
> > > From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> > > Sent: Tuesday, December 20, 2016 7:17 AM
> > > To: Yu, Xiangliang <xiangliang...@amd.com>
> > > Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>;
> > > dl.SRDC_SW_GPUVirtualization
> > <dl.srdc_sw_gpuvirtualizat...@amd.com>
> > > Subject: Re: [PATCH 09/23] drm/amdgpu: enable virtualization feature
> > > for FIJI/TONGA
> > >
> > > On Sat, Dec 17, 2016 at 11:16 AM, Xiangliang Yu
> > > <xiangliang...@amd.com>
> > > wrote:
> > > > According to chip device id to set VF flag, and call virtual
> > > > interface to setup all realted IP blocks.
> > > >
> > > > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > > > ---
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 -
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 ++--
> > > >  2 files changed, 6 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > index c4075b7..ab8c8bb5 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > @@ -1285,7 +1285,10 @@ static int amdgpu_early_init(struct
> > > amdgpu_device *adev)
> > > > else
> > > > adev->family = AMDGPU_FAMILY_VI;
> > > >
> > > > -   r = vi_set_ip_blocks(adev);
> > > > +   if (adev->flags & AMD_IS_VF)
> > > > +   r = amd_xgpu_set_ip_blocks(adev);
> > >
> > > As far as I can see there's no need for a special
> > > amd_xgpu_set_ip_blocks() function.  Just handle the VF case directly
> > > in
> > > vi_set_ip_blocks() and avoid all the extra indirection.
> >
> > My idea is that all virtualization chip share one common interface as
> > a special chip family.  It will bring some benefits:
> > 1. Logic code is very clear;
> > 2. Avoid to scatter virtualization code throughout all amdgpu
> > components; 3. Easy to support next virtualization chip without change
> > amdgpu code;
> >
> 
> I don't mind having a separate IP module for special VF related setup, but I
> think the differences in the list of IP modules is small enough that it 
> doesn't
> warrant all of the redirection.  Basically just:
> 
> if (VF) {
> add_ip_module(A);
> add_ip_module(X);
> add_ip_module(C);
> } else {
> add_ip_module(A);
> add_ip_module(B);
> add_ip_module(C);
> add_ip_module(D);
> }
> 
> That way it's obvious in one place which modules are present in the VF and
> bare metal cases without having to trace through a bunch of indirection.  It
> also makes it easier to update the lists if we ever rework the ip module
> interface or add a new IP module or something like that.

My point is we want to centrally manage all virtualization, like as power play 
component does. 
For you, the code is not big difference, but for us, easy to implement new 
features, support new chips, and add new setting for virtualization.
Otherwise, there are lot of virtualization check in amdgpu and bring lot of 
effects to maintain virtualization code. 
You know, virtualization is very big feature for graphics.

Please think about from what I'm standing.

> > >
> > > > +   else
> > > > +   r = vi_set_ip_blocks(adev);
> > > > if (r)
> > > > return r;
> > > > break;
> > > > diff --git a/drivers/gpu/drm/

RE: [PATCH 1/1] drm/amdgpu/gfx8: add support kernel interface queue(KIQ)

2016-12-20 Thread Yu, Xiangliang
Ignore the patch, forget add Monk name into signed-off


Thanks!
Xiangliang Yu


> -Original Message-
> From: Xiangliang Yu [mailto:xiangliang...@amd.com]
> Sent: Tuesday, December 20, 2016 5:41 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang <xiangliang...@amd.com>
> Subject: [PATCH 1/1] drm/amdgpu/gfx8: add support kernel interface
> queue(KIQ)
> 
> KIQ is queue-memory based initialization method: setup KIQ queue firstly,
> then send command to KIQ to setup other queues, without accessing
> registers.
> 
> For virtualization, need KIQ to access virtual function registers when running
> on guest mode.
> 
> Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  13 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 643
> +-
>  drivers/gpu/drm/amd/amdgpu/vid.h  |   2 +
>  3 files changed, 656 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 9ea5bf0..c392882 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -186,6 +186,11 @@ enum amdgpu_thermal_irq {
>   AMDGPU_THERMAL_IRQ_LAST
>  };
> 
> +enum amdgpu_kiq_irq {
> + AMDGPU_CP_KIQ_IRQ_DRIVER0 = 0,
> + AMDGPU_CP_KIQ_IRQ_LAST
> +};
> +
>  int amdgpu_set_clockgating_state(struct amdgpu_device *adev,
> enum amd_ip_block_type block_type,
> enum amd_clockgating_state state); @@ -
> 778,6 +783,13 @@ struct amdgpu_mec {
>   u32 num_queue;
>  };
> 
> +struct amdgpu_kiq {
> + u64 eop_gpu_addr;
> + struct amdgpu_bo*eop_obj;
> + struct amdgpu_ring  ring;
> + struct amdgpu_irq_src   irq;
> +};
> +
>  /*
>   * GPU scratch registers structures, functions & helpers
>   */
> @@ -853,6 +865,7 @@ struct amdgpu_gfx {
>   struct amdgpu_gca_configconfig;
>   struct amdgpu_rlc   rlc;
>   struct amdgpu_mec   mec;
> + struct amdgpu_kiq   kiq;
>   struct amdgpu_scratch   scratch;
>   const struct firmware   *me_fw; /* ME firmware */
>   uint32_tme_fw_version;
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index c3e6bfc..3569e5e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -1367,6 +1367,42 @@ static void gfx_v8_0_mec_fini(struct
> amdgpu_device *adev)
>   }
>  }
> 
> +static int gfx_v8_0_kiq_init_ring(struct amdgpu_device *adev,
> +   struct amdgpu_ring *ring,
> +   struct amdgpu_irq_src *irq)
> +{
> + int r = 0;
> +
> + ring->adev = NULL;
> + ring->ring_obj = NULL;
> + ring->use_doorbell = true;
> + ring->doorbell_index = AMDGPU_DOORBELL_KIQ;
> + if (adev->gfx.mec2_fw) {
> + ring->me = 2;
> + ring->pipe = 0;
> + } else {
> + ring->me = 1;
> + ring->pipe = 1;
> + }
> +
> + irq->data = ring;
> + ring->queue = 0;
> + sprintf(ring->name, "kiq %d.%d.%d", ring->me, ring->pipe, ring-
> >queue);
> + r = amdgpu_ring_init(adev, ring, 1024,
> +  irq, AMDGPU_CP_KIQ_IRQ_DRIVER0);
> + if (r)
> + dev_warn(adev->dev, "(%d) failed to init kiq ring\n", r);
> +
> + return r;
> +}
> +
> +static void gfx_v8_0_kiq_free_ring(struct amdgpu_ring *ring,
> +struct amdgpu_irq_src *irq)
> +{
> + amdgpu_ring_fini(ring);
> + irq->data = NULL;
> +}
> +
>  #define MEC_HPD_SIZE 2048
> 
>  static int gfx_v8_0_mec_init(struct amdgpu_device *adev) @@ -1421,6
> +1457,69 @@ static int gfx_v8_0_mec_init(struct amdgpu_device *adev)
>   return 0;
>  }
> 
> +static void gfx_v8_0_kiq_fini(struct amdgpu_device *adev) {
> + int r;
> + struct amdgpu_kiq *kiq = >gfx.kiq;
> +
> + if (kiq->eop_obj) {
> + r = amdgpu_bo_reserve(kiq->eop_obj, false);
> + if (unlikely(r != 0))
> + dev_warn(adev->dev, "(%d) reserve HPD EOP bo
> failed\n", r);
> + amdgpu_bo_unpin(kiq->eop_obj);
> + amdgpu_bo_unreserve(kiq->eop_obj);
> + amdgpu_bo_unref(>eop_obj);
> + kiq->eop_obj = NULL;
> + }
> +}
> +
> +static int gfx_v8_0_

RE: [PATCH 13/23] drm/amdgpu/mxgpu: add support for mailbox communication

2016-12-19 Thread Yu, Xiangliang

> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: Tuesday, December 20, 2016 7:25 AM
> To: Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>;
> dl.SRDC_SW_GPUVirtualization
> <dl.srdc_sw_gpuvirtualizat...@amd.com>; Liu, Shaoyun
> <shaoyun@amd.com>
> Subject: Re: [PATCH 13/23] drm/amdgpu/mxgpu: add support for mailbox
> communication
> 
> On Sat, Dec 17, 2016 at 11:16 AM, Xiangliang Yu <xiangliang...@amd.com>
> wrote:
> > GPU guest driver send mailbox messages to hyperverisor to request full
> > access to all of registers and release it when access is done.
> >
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > Signed-off-by: shaoyunl <shaoyun@amd.com>
> > ---
> >  drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h |   3 +
> >  drivers/gpu/drm/amd/mxgpu/mxgpu_mb.c  | 128
> > ++
> >  2 files changed, 131 insertions(+)
> >  create mode 100644 drivers/gpu/drm/amd/mxgpu/mxgpu_mb.c
> >
> > diff --git a/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > b/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > index cc3123b..54e7b31 100644
> > --- a/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > +++ b/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > @@ -85,4 +85,7 @@ extern void amd_xgpu_free(struct amd_xgpu *xgpu);
> >
> >  extern int xgpu_allocate_csa(struct amd_xgpu *xgpu);  extern void
> > xgpu_destroy_csa(struct amd_xgpu_csa *csa);
> > +
> > +extern int xgpu_request_full_gpu_access(struct amdgpu_device *adev,
> > +bool init); extern int xgpu_release_full_gpu_access(struct
> > +amdgpu_device *adev, bool init);
> >  #endif
> > diff --git a/drivers/gpu/drm/amd/mxgpu/mxgpu_mb.c
> > b/drivers/gpu/drm/amd/mxgpu/mxgpu_mb.c
> > new file mode 100644
> > index 000..b74b501
> > --- /dev/null
> > +++ b/drivers/gpu/drm/amd/mxgpu/mxgpu_mb.c
> > @@ -0,0 +1,128 @@
> > +/*
> > + * Copyright 2016 Advanced Micro Devices, Inc.
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > +obtaining a
> > + * copy of this software and associated documentation files (the
> > +"Software"),
> > + * to deal in the Software without restriction, including without
> > +limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > +sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom
> > +the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > +included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> > +EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > +MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN
> NO EVENT
> > +SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> > +DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> > +OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
> THE USE
> > +OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + *
> > + * Authors: xiangliang...@amd.com
> > + */
> > +#include "amd_mxgpu.h"
> > +#include "bif/bif_5_0_d.h"
> > +#include "bif/bif_5_0_sh_mask.h"
> > +
> > +/* mailbox messages request */
> > +enum idh_request {
> > +   IDH_REQ_GPU_INIT_ACCESS = 1,
> > +   IDH_REL_GPU_INIT_ACCESS,
> > +   IDH_REQ_GPU_FINI_ACCESS,
> > +   IDH_REL_GPU_FINI_ACCESS,
> > +   IDH_REQ_GPU_RESET_ACCESS
> > +};
> > +
> > +/* mailbox messages data */
> > +enum idh_event {
> > +   IDH_CLR_MSG_BUF = 0,
> > +   IDH_READY_TO_ACCESS_GPU,
> > +   IDH_FLR_NOTIFICATION,
> > +   IDH_FLR_NOTIFICATION_CMPL
> > +};
> > +
> > +/* mailbox state */
> > +enum mail_state {
> > +   AMDGPU_START_INIT = 1,
> > +   AMDGPU_END_INIT,
> > +   AMDGPU_START_FINI,
> > +   AMDGPU_END_FINI,
> > +};
> > +
> > +/*
> > + * Mailbox communicate between PF and VF  */ static int
> > +xgpu_request_reg_access(struct amdgpu_device *adev,
> > +  enum mail_state state) {
> > +   u32 temp, timeout = 15;
> > +   u32 req = IDH_R

RE: [PATCH 19/23] drm/amdgpu/mxgpu: add implementation of GPU virtualization of VI

2016-12-19 Thread Yu, Xiangliang

> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: Tuesday, December 20, 2016 7:35 AM
> To: Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>;
> dl.SRDC_SW_GPUVirtualization <dl.srdc_sw_gpuvirtualizat...@amd.com>
> Subject: Re: [PATCH 19/23] drm/amdgpu/mxgpu: add implementation of
> GPU virtualization of VI
> 
> On Sat, Dec 17, 2016 at 11:16 AM, Xiangliang Yu <xiangliang...@amd.com>
> wrote:
> > Different chips will have different virtual behaviors, so need to
> > implemnt different virtual feature according to hardware design.
> >
> > This patch will implemnt Vi family virtualization, it will call CSA,
> > mailbox interface and allocate wb offset for KIQ.
> >
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >  drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h |   2 +
> >  drivers/gpu/drm/amd/mxgpu/mxgpu_vi.c  | 205
> > ++
> >  2 files changed, 207 insertions(+)
> >  create mode 100644 drivers/gpu/drm/amd/mxgpu/mxgpu_vi.c
> >
> > diff --git a/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > b/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > index 54e7b31..02a8839 100644
> > --- a/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > +++ b/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > @@ -88,4 +88,6 @@ extern void xgpu_destroy_csa(struct amd_xgpu_csa
> > *csa);
> >
> >  extern int xgpu_request_full_gpu_access(struct amdgpu_device *adev,
> > bool init);  extern int xgpu_release_full_gpu_access(struct
> > amdgpu_device *adev, bool init);
> > +
> > +extern void xgpu_vi_add_ip_blocks(struct amdgpu_device *adev);
> >  #endif
> > diff --git a/drivers/gpu/drm/amd/mxgpu/mxgpu_vi.c
> > b/drivers/gpu/drm/amd/mxgpu/mxgpu_vi.c
> > new file mode 100644
> > index 000..e5d517f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/amd/mxgpu/mxgpu_vi.c
> > @@ -0,0 +1,205 @@
> > +/*
> > + * Copyright 2016 Advanced Micro Devices, Inc.
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > +obtaining a
> > + * copy of this software and associated documentation files (the
> > +"Software"),
> > + * to deal in the Software without restriction, including without
> > +limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > +sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom
> > +the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > +included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> > +EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > +MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN
> NO EVENT
> > +SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> > +DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> > +OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
> THE USE
> > +OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + *
> > + * Author: xiangliang...@amd.com
> > + */
> > +#include "amd_mxgpu.h"
> > +#include "vi.h"
> > +#include "gmc_v8_0.h"
> > +#include "gfx_v8_0.h"
> > +#include "sdma_v3_0.h"
> > +#include "tonga_ih.h"
> > +#include "gmc/gmc_8_2_d.h"
> > +#include "gmc/gmc_8_2_sh_mask.h"
> > +#include "oss/oss_3_0_d.h"
> > +#include "oss/oss_3_0_sh_mask.h"
> > +#include "bif/bif_5_0_d.h"
> > +#include "bif/bif_5_0_sh_mask.h"
> > +#include "amdgpu_powerplay.h"
> > +#include "dce_virtual.h"
> > +#include "gca/gfx_8_0_d.h"
> > +#include "gca/gfx_8_0_enum.h"
> > +#include "gca/gfx_8_0_sh_mask.h"
> > +#include "dce/dce_10_0_d.h"
> > +#include "dce/dce_10_0_sh_mask.h"
> > +#include "smu/smu_7_1_3_d.h"
> 
> You don't need all of these register headers.  there aren't even any registers
> used in this code.

The headers is need by golden setting.

> 
> 
> > +
> > +static int xgpu_vi_early_init(void *handle) {
> > +   struct amdgpu_device *adev = (struct amdgp

RE: [PATCH 21/23] drm/amdgpu: change golden register program sequence of virtualization

2016-12-19 Thread Yu, Xiangliang
Thank monk’s comments.


From: Liu, Monk
Sent: Tuesday, December 20, 2016 12:09 PM
To: Alex Deucher <alexdeuc...@gmail.com>; Yu, Xiangliang <xiangliang...@amd.com>
Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>; dl.SRDC_SW_GPUVirtualization 
<dl.srdc_sw_gpuvirtualizat...@amd.com>; Min, Frank <frank@amd.com>
Subject: 答复: [PATCH 21/23] drm/amdgpu: change golden register program sequence 
of virtualization


Hi Alex



I agree with you that this patch's GOLDEN setting programming should be put in 
VI.C, but I found a hardware issue :



original linux logic is that we set golden setting registers separately within 
each IP's hw init routine, but for TONGA VF, it is really strange that we must 
set all GOLDEN setting value to chip in one shoot (means we use one routine to 
programing all IP's golden setting to registers), ortherwise we found TONGA vf  
just failed in RING TEST.



and I admit I don't know why (I checked windows CAIL code, it is also set all 
golden setting registers in one routine)



BR Monk


发件人: Alex Deucher <alexdeuc...@gmail.com<mailto:alexdeuc...@gmail.com>>
发送时间: 2016年12月20日 7:37:06
收件人: Yu, Xiangliang
抄送: amd-gfx list; dl.SRDC_SW_GPUVirtualization; Min, Frank; Liu, Monk
主题: Re: [PATCH 21/23] drm/amdgpu: change golden register program sequence of 
virtualization

On Sat, Dec 17, 2016 at 11:16 AM, Xiangliang Yu 
<xiangliang...@amd.com<mailto:xiangliang...@amd.com>> wrote:
> GPU virtualization has different sequence from normal, change it.
>
> Signed-off-by: Frank Min <frank@amd.com<mailto:frank@amd.com>>
> Signed-off-by: Monk Liu <monk....@amd.com<mailto:monk@amd.com>>
> Signed-off-by: Xiangliang Yu 
> <xiangliang...@amd.com<mailto:xiangliang...@amd.com>>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |   2 +
>  drivers/gpu/drm/amd/amdgpu/vi.c  |   6 +
>  drivers/gpu/drm/amd/mxgpu/mxgpu_vi.c | 267 
> +++
>  3 files changed, 275 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> index eb2905e..e781c9c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> @@ -84,4 +84,6 @@ int amdgpu_put_gpu(struct amdgpu_device *adev);
>  /* access vf registers */
>  uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev, uint32_t reg);
>  void amdgpu_kiq_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v);
> +
> +void amdgpu_xgpu_init_golden_registers(struct amdgpu_device *adev);
>  #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index 5229b4a2a..0d5e807 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -285,6 +285,12 @@ static void vi_init_golden_registers(struct 
> amdgpu_device *adev)
> /* Some of the registers might be dependent on GRBM_GFX_INDEX */
> mutex_lock(>grbm_idx_mutex);
>
> +   if (adev->flags & AMD_IS_VF) {
> +   amdgpu_xgpu_init_golden_registers(adev);
> +   mutex_unlock(>grbm_idx_mutex);
> +   return;
> +   }
> +
> switch (adev->asic_type) {
> case CHIP_TOPAZ:
> amdgpu_program_register_sequence(adev,
> diff --git a/drivers/gpu/drm/amd/mxgpu/mxgpu_vi.c 
> b/drivers/gpu/drm/amd/mxgpu/mxgpu_vi.c
> index e5d517f..fa1ee8f 100644
> --- a/drivers/gpu/drm/amd/mxgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/mxgpu/mxgpu_vi.c
> @@ -42,6 +42,273 @@
>  #include "dce/dce_10_0_sh_mask.h"
>  #include "smu/smu_7_1_3_d.h"
>
> +static const u32 xgpu_fiji_mgcg_cgcg_init[] = {
> +   mmRLC_CGTT_MGCG_OVERRIDE, 0x, 0x,
> +   mmGRBM_GFX_INDEX, 0x, 0xe000,
> +   mmCB_CGTT_SCLK_CTRL, 0x, 0x0100,
> +   mmCGTT_BCI_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_CP_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_CPC_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_CPF_CLK_CTRL, 0x, 0x4100,
> +   mmCGTT_DRM_CLK_CTRL0, 0x, 0x00600100,
> +   mmCGTT_GDS_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_IA_CLK_CTRL, 0x, 0x06000100,
> +   mmCGTT_PA_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_WD_CLK_CTRL, 0x, 0x06000100,
> +   mmCGTT_PC_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_RLC_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_SC_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_SPI_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_SQ_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_SQG_CLK_CTRL, 0x, 0x0100,
> +   mmCGTT_SX_CLK_CTRL0, 0x

RE: [PATCH 15/23] drm/amdgpu/mxgpu: implement register access function with KIQ

2016-12-19 Thread Yu, Xiangliang


> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: Tuesday, December 20, 2016 7:27 AM
> To: Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>;
> dl.SRDC_SW_GPUVirtualization
> <dl.srdc_sw_gpuvirtualizat...@amd.com>; Liu, Monk
> <monk@amd.com>
> Subject: Re: [PATCH 15/23] drm/amdgpu/mxgpu: implement register access
> function with KIQ
> 
> On Sat, Dec 17, 2016 at 11:16 AM, Xiangliang Yu <xiangliang...@amd.com>
> wrote:
> > One of important role of KIQ is provide one way to access VF
> > registers. This patch implement the feature and export interfaces.
> >
> > Signed-off-by: Monk Liu <monk@amd.com>
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |   4 ++
> >  drivers/gpu/drm/amd/mxgpu/mxgpu_kiq.c| 110
> +++
> >  2 files changed, 114 insertions(+)
> >  create mode 100644 drivers/gpu/drm/amd/mxgpu/mxgpu_kiq.c
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > index 97aae31..c78435d 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > @@ -75,4 +75,8 @@ void amdgpu_gfx_ring_emit_meta_data(struct
> > amdgpu_ring *ring,
> >  /* get full gpu access */
> >  int amdgpu_get_gpu(struct amdgpu_device *adev);  int
> > amdgpu_put_gpu(struct amdgpu_device *adev);
> > +
> > +/* access vf registers */
> > +uint32_t amdgpu_kiq_rreg(struct amdgpu_device *adev, uint32_t reg);
> > +void amdgpu_kiq_wreg(struct amdgpu_device *adev, uint32_t reg,
> > +uint32_t v);
> >  #endif
> > diff --git a/drivers/gpu/drm/amd/mxgpu/mxgpu_kiq.c
> > b/drivers/gpu/drm/amd/mxgpu/mxgpu_kiq.c
> > new file mode 100644
> > index 000..6e1b8e3
> > --- /dev/null
> > +++ b/drivers/gpu/drm/amd/mxgpu/mxgpu_kiq.c
> > @@ -0,0 +1,110 @@
> > +/*
> > + * Copyright 2016 Advanced Micro Devices, Inc.
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > +obtaining a
> > + * copy of this software and associated documentation files (the
> > +"Software"),
> > + * to deal in the Software without restriction, including without
> > +limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > +sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom
> > +the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > +included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> > +EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > +MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN
> NO EVENT
> > +SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> > +DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> > +OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
> THE USE
> > +OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + *
> > + * Authors: xiangliang...@amd.com
> > + * monk@amd.com
> > + */
> > +#include "amd_mxgpu.h"
> > +#include "vid.h"
> > +#include "gca/gfx_8_0_d.h"
> > +#include "gca/gfx_8_0_sh_mask.h"
> > +
> > +static void xgpu_kiq_ring_emit_rreg(struct amdgpu_ring *ring, u32
> > +idx) {
> > +   struct amdgpu_device *adev = ring->adev;
> > +   struct amd_xgpu *xgpu = (struct amd_xgpu *)adev->priv_data;
> > +
> > +   amdgpu_ring_write(ring, PACKET3(PACKET3_COPY_DATA, 4));
> > +   amdgpu_ring_write(ring, 0 | /* src: register*/
> > +   (5 << 8) |  /* dst: memory */
> > +   (1 << 20)); /* write confirm */
> > +   amdgpu_ring_write(ring, idx);
> > +   amdgpu_ring_write(ring, 0);
> > +   amdgpu_ring_write(ring, lower_32_bits(adev->wb.gpu_addr +
> > +   xgpu->reg_val_offs * 4));
> > +   amdgpu_ring_write(ring, upper_32_bits(adev->wb.gpu_addr +
> > +   xgpu->reg_val_offs *

RE: [PATCH 12/23] drm/amdgpu: Insert meta data during submitting IB

2016-12-19 Thread Yu, Xiangliang

> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: Tuesday, December 20, 2016 7:23 AM
> To: Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>;
> dl.SRDC_SW_GPUVirtualization
> <dl.srdc_sw_gpuvirtualizat...@amd.com>; Liu, Monk
> <monk@amd.com>
> Subject: Re: [PATCH 12/23] drm/amdgpu: Insert meta data during submitting
> IB
> 
> On Sat, Dec 17, 2016 at 11:16 AM, Xiangliang Yu <xiangliang...@amd.com>
> wrote:
> > Virtualization world switch need each command that is submitted into
> > GFX with an extra entry, which will using WRITE_DATA to fullfill CSA.
> > In this way, CP will save CE/DE snapshots when preemption occurred and
> > restore it later.
> >
> > Signed-off-by: Monk Liu <monk@amd.com>
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   |  2 +
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |  2 +
> >  drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h| 39 ++
> >  drivers/gpu/drm/amd/mxgpu/mxgpu_csa.c| 88
> 
> >  4 files changed, 131 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> > index acf48de..cc35255 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> > @@ -175,6 +175,8 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring,
> unsigned num_ibs,
> > if (ring->funcs->emit_hdp_flush)
> > amdgpu_ring_emit_hdp_flush(ring);
> >
> > +   amdgpu_gfx_ring_emit_meta_data(ring, vm);
> > +
> > /* always set cond_exec_polling to CONTINUE */
> > *ring->cond_exe_cpu_addr = 1;
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > index dff1248..d6f57a2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> > @@ -69,4 +69,6 @@ int amd_xgpu_set_ip_blocks(struct amdgpu_device
> > *adev);
> >  /* Context Save Area functions */
> >  int amdgpu_vm_map_csa(struct amdgpu_device *adev, struct
> amdgpu_vm
> > *vm);  void amdgpu_vm_unmap_csa(struct amdgpu_device *adev, struct
> > amdgpu_vm *vm);
> > +void amdgpu_gfx_ring_emit_meta_data(struct amdgpu_ring *ring,
> > +   struct amdgpu_vm *vm);
> >  #endif
> > diff --git a/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > b/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > index a25e07f..cc3123b 100644
> > --- a/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > +++ b/drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h
> > @@ -26,9 +26,48 @@
> >
> >  #include "amdgpu.h"
> >
> > +/* context save area structures */
> > +struct amdgpu_ce_ib_state {
> > +   uint32_tce_ib_completion_status;
> > +   uint32_tce_const_engine_count;
> > +   uint32_tce_ib_offset_ib1;
> > +   uint32_tce_ib_offset_ib2;
> > +};
> > +
> > +struct amdgpu_de_ib_state {
> > +   uint32_tde_ib_completion_status;
> > +   uint32_tde_const_engine_count;
> > +   uint32_tde_ib_offset_ib1;
> > +   uint32_tde_ib_offset_ib2;
> > +   uint32_tpreamble_begin_ib1;
> > +   uint32_tpreamble_begin_ib2;
> > +   uint32_tpreamble_end_ib1;
> > +   uint32_tpreamble_end_ib2;
> > +   uint32_tdraw_indirect_base_lo;
> > +   uint32_tdraw_indirect_base_hi;
> > +   uint32_tdisp_indirect_base_lo;
> > +   uint32_tdisp_indirect_base_hi;
> > +   uint32_tgds_backup_addr_lo;
> > +   uint32_tgds_backup_addr_hi;
> > +   uint32_tindex_base_addr_lo;
> > +   uint32_tindex_base_addr_hi;
> > +   uint32_tsample_cntl;
> > +};
> > +
> > +struct amdgpu_gfx_meta_data {
> > +   struct amdgpu_ce_ib_state   ce_payload;
> > +   uint32_treserved1[60];
> > +   struct amdgpu_de_ib_state   de_payload;
> > +   uint32_tde_ib_base_addr_lo;
> > +   uint32_tde_ib_base_addr_hi;
> > +   uint32_treserved2[941];
> > +};
> > +
> 
> These are gfx8 specific and should be moved to gfx8 module.

I think it is only relate 

RE: [PATCH 11/23] drm/amdgpu: implement context save area(CSA) feature

2016-12-19 Thread Yu, Xiangliang
Thank monk’s detail expanation.
And I think this patch is only support virtualization world switch, not touch 
whole amdpgu preemption.

Thanks!
Xiangliang Yu

From: Liu, Monk
Sent: Tuesday, December 20, 2016 11:58 AM
To: Alex Deucher <alexdeuc...@gmail.com>; Yu, Xiangliang <xiangliang...@amd.com>
Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>; dl.SRDC_SW_GPUVirtualization 
<dl.srdc_sw_gpuvirtualizat...@amd.com>
Subject: 答复: [PATCH 11/23] drm/amdgpu: implement context save area(CSA) feature


the CSA is used for world switch, and each amdgpu device should have one and 
only one CSA,

and this CSA will pined, and mapped to each virtual memory /process.



CP/RLCV will use this CSA buffer when preemption occurred, and will write some 
hardware status into this CSA buffer, within the current IB's context (that's 
why need do mapping for each virtual memory on CSA)



BR Monk


发件人: Alex Deucher <alexdeuc...@gmail.com<mailto:alexdeuc...@gmail.com>>
发送时间: 2016年12月20日 7:20:09
收件人: Yu, Xiangliang
抄送: amd-gfx list; dl.SRDC_SW_GPUVirtualization; Liu, Monk
主题: Re: [PATCH 11/23] drm/amdgpu: implement context save area(CSA) feature

On Sat, Dec 17, 2016 at 11:16 AM, Xiangliang Yu 
<xiangliang...@amd.com<mailto:xiangliang...@amd.com>> wrote:
> CSA is need by world switch. This patch implement CSA feature and
> bind it to each VM, so hardware can save the state into the area
> and restore it when running again.
>
> Signed-off-by: Monk Liu <monk....@amd.com<mailto:monk@amd.com>>
> Signed-off-by: Xiangliang Yu 
> <xiangliang...@amd.com<mailto:xiangliang...@amd.com>>

Isn't the CSA actually for preemption?  Preemption is useful outside
of the VF case as well so it should be untangled from the mxgpu code
so it can be utilized independently.

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |  14 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   |   8 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h   |   4 +
>  drivers/gpu/drm/amd/mxgpu/amd_mxgpu.h|  12 ++
>  drivers/gpu/drm/amd/mxgpu/mxgpu_csa.c| 209 
> +++
>  5 files changed, 247 insertions(+)
>  create mode 100644 drivers/gpu/drm/amd/mxgpu/mxgpu_csa.c
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> index 8ee70f8..dff1248 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> @@ -24,6 +24,8 @@
>  #ifndef AMDGPU_VIRT_H
>  #define AMDGPU_VIRT_H
>
> +struct amdgpu_vm;
> +
>  #define AMDGPU_SRIOV_CAPS_SRIOV_VBIOS  (1 << 0) /* vBIOS is sr-iov ready */
>  #define AMDGPU_SRIOV_CAPS_ENABLE_IOV   (1 << 1) /* sr-iov is enabled on this 
> GPU */
>  #define AMDGPU_SRIOV_CAPS_IS_VF(1 << 2) /* this GPU is a virtual 
> function */
> @@ -33,6 +35,14 @@ struct amdgpu_virtualization {
> uint32_t virtual_caps;
>  };
>
> +struct amdgpu_csa {
> +   struct amdgpu_bo_va *va;
> +   struct ttm_validate_buffer  tv;
> +   uint64_treserved_top;
> +   uint64_tcsa_addr;
> +   uint64_tgds_addr;
> +};
> +
>  #define amdgpu_sriov_enabled(adev) \
>  ((adev)->virtualization.virtual_caps & AMDGPU_SRIOV_CAPS_ENABLE_IOV)
>
> @@ -55,4 +65,8 @@ static inline bool is_virtual_machine(void)
>  }
>
>  int amd_xgpu_set_ip_blocks(struct amdgpu_device *adev);
> +
> +/* Context Save Area functions */
> +int amdgpu_vm_map_csa(struct amdgpu_device *adev, struct amdgpu_vm *vm);
> +void amdgpu_vm_unmap_csa(struct amdgpu_device *adev, struct amdgpu_vm *vm);
>  #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index d05546e..98540d9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1539,6 +1539,8 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
> amdgpu_vm *vm)
> pd_size = amdgpu_vm_directory_size(adev);
> pd_entries = amdgpu_vm_num_pdes(adev);
>
> +   vm->csa.reserved_top = AMDGPU_VA_RESERVED_SIZE;
> +
> /* allocate page table array */
> vm->page_tables = drm_calloc_large(pd_entries, sizeof(struct 
> amdgpu_vm_pt));
> if (vm->page_tables == NULL) {
> @@ -1576,6 +1578,10 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
> amdgpu_vm *vm)
> vm->last_eviction_counter = atomic64_read(>num_evictions);
> amdgpu_bo_unreserve(vm->page_directory);
>
> +   r = amdgpu_vm_map_csa(adev, vm);
> +   if (r)
> +   goto error_free_page_directory;
> +
> return 0;
>

RE: [PATCH 06/23] drm/amdgpu/gfx8: correct KIQ hdp flush

2016-12-19 Thread Yu, Xiangliang

> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: Tuesday, December 20, 2016 7:14 AM
> To: Yu, Xiangliang <xiangliang...@amd.com>
> Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>;
> dl.SRDC_SW_GPUVirtualization <dl.srdc_sw_gpuvirtualizat...@amd.com>
> Subject: Re: [PATCH 06/23] drm/amdgpu/gfx8: correct KIQ hdp flush
> 
> On Sat, Dec 17, 2016 at 11:16 AM, Xiangliang Yu <xiangliang...@amd.com>
> wrote:
> > KIQ has some behavior as compute ring.
> >
> > Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> 
> Should be squashed into patch 5.

Sure. 

> 
> Alex
> 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > index ae20cd9..a5a9a8e 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > @@ -6196,7 +6196,8 @@ static void gfx_v8_0_ring_emit_hdp_flush(struct
> > amdgpu_ring *ring)  {
> > u32 ref_and_mask, reg_mem_engine;
> >
> > -   if (ring->funcs->type == AMDGPU_RING_TYPE_COMPUTE) {
> > +   if ((ring->funcs->type == AMDGPU_RING_TYPE_COMPUTE) ||
> > +   (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)) {
> > switch (ring->me) {
> > case 1:
> > ref_and_mask = GPU_HDP_FLUSH_DONE__CP2_MASK <<
> > ring->pipe;
> > --
> > 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


  1   2   >