All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
@ 2018-11-23  8:32 Junwei Zhang
       [not found] ` <20181123083227.25555-1-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 12+ messages in thread
From: Junwei Zhang @ 2018-11-23  8:32 UTC (permalink / raw)
  To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW; +Cc: Junwei Zhang

Some variants don't support UVD and VCE.

Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index f3a4cf1f013a..3338b013ded4 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
 			amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
 		amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
 		amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
+		/* Some polaris12 variants don't support UVD/VCE */
+		if ((adev->pdev->device == 0x67df) &&
+		      (adev->pdev->revision == 0xf7))
+			break;
 		amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
 		amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
 		break;
-- 
2.17.1

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

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* RE: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
       [not found] ` <20181123083227.25555-1-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
@ 2018-11-23  9:19   ` Cui, Flora
  2018-11-23 19:32   ` Deucher, Alexander
  1 sibling, 0 replies; 12+ messages in thread
From: Cui, Flora @ 2018-11-23  9:19 UTC (permalink / raw)
  To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW; +Cc: Zhang, Jerry

Patch is Reviewed-by: Flora Cui <flora.cui@amd.com>

-----Original Message-----
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Junwei Zhang
Sent: Friday, November 23, 2018 4:32 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jerry <Jerry.Zhang@amd.com>
Subject: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants

Some variants don't support UVD and VCE.

Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c index f3a4cf1f013a..3338b013ded4 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
 			amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
 		amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
 		amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
+		/* Some polaris12 variants don't support UVD/VCE */
+		if ((adev->pdev->device == 0x67df) &&
+		      (adev->pdev->revision == 0xf7))
+			break;
 		amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
 		amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
 		break;
--
2.17.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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
       [not found] ` <20181123083227.25555-1-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
  2018-11-23  9:19   ` Cui, Flora
@ 2018-11-23 19:32   ` Deucher, Alexander
       [not found]     ` <BN6PR12MB18091B4409C1DC5CD17F903CF7D40-/b2+HYfkarSEx6ez0IUAagdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
  1 sibling, 1 reply; 12+ messages in thread
From: Deucher, Alexander @ 2018-11-23 19:32 UTC (permalink / raw)
  To: Zhang, Jerry, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW


[-- Attachment #1.1: Type: text/plain, Size: 2297 bytes --]

Is this required?  Are the harvesting fuses incorrect?  If the blocks are harvested, we should bail out of the blocks properly during init.  Also, please make this more explicit if we still need it.  E.g.,

       if ((adev->pdev->device == 0x67df) &&
              (adev->pdev->revision == 0xf7)) {

        /* Some polaris12 variants don't support UVD/VCE */

      } else  {

                 amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);

                 amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);

    }


That way if we re-arrange the order later, it will be easier to track.


Alex

________________________________
From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
Sent: Friday, November 23, 2018 3:32:27 AM
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: Zhang, Jerry
Subject: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants

Some variants don't support UVD and VCE.

Signed-off-by: Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index f3a4cf1f013a..3338b013ded4 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
                         amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
                 amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
                 amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
+               /* Some polaris12 variants don't support UVD/VCE */
+               if ((adev->pdev->device == 0x67df) &&
+                     (adev->pdev->revision == 0xf7))
+                       break;
                 amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
                 amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
                 break;
--
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[-- Attachment #1.2: Type: text/html, Size: 5402 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

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

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
       [not found]     ` <BN6PR12MB18091B4409C1DC5CD17F903CF7D40-/b2+HYfkarSEx6ez0IUAagdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
@ 2018-11-26  2:38       ` Zhang, Jerry(Junwei)
       [not found]         ` <b8a49f59-e466-b0e7-abf8-feedf1bf1946-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 12+ messages in thread
From: Zhang, Jerry(Junwei) @ 2018-11-26  2:38 UTC (permalink / raw)
  To: Deucher, Alexander, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW


[-- Attachment #1.1: Type: text/plain, Size: 2883 bytes --]

On 11/24/18 3:32 AM, Deucher, Alexander wrote:
>
> Is this required?  Are the harvesting fuses incorrect?  If the blocks 
> are harvested, we should bail out of the blocks properly during init. 
>  Also, please make this more explicit if we still need it.  E.g.,
>
>

The harvest fuse is indeed disabling UVD and VCE, as it's a mining card.
Then any command to UVD/VCE causing NULL pointer issue, like amdgpu_test.

AFAIW, windows also disable UVD and VCE in initialization.

>        if ((adev->pdev->device == 0x67df) &&
>               (adev->pdev->revision == 0xf7)) {
>
> /* Some polaris12 variants don't support UVD/VCE */
>
>       } else  {
>
> amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>
> amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>
>     }
>
>

OK, will explicit the process.

Regards,
Jerry
>
> That way if we re-arrange the order later, it will be easier to track.
>
>
> Alex
>
> ------------------------------------------------------------------------
> *From:* amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of 
> Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
> *Sent:* Friday, November 23, 2018 3:32:27 AM
> *To:* amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> *Cc:* Zhang, Jerry
> *Subject:* [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 
> variants
> Some variants don't support UVD and VCE.
>
> Signed-off-by: Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
> ---
>  drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c 
> b/drivers/gpu/drm/amd/amdgpu/vi.c
> index f3a4cf1f013a..3338b013ded4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
>                          amdgpu_device_ip_block_add(adev, 
> &dce_v11_2_ip_block);
>                  amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
>                  amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
> +               /* Some polaris12 variants don't support UVD/VCE */
> +               if ((adev->pdev->device == 0x67df) &&
> +                     (adev->pdev->revision == 0xf7))
> +                       break;
>                  amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>                  amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>                  break;
> -- 
> 2.17.1
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[-- Attachment #1.2: Type: text/html, Size: 7492 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
       [not found]         ` <b8a49f59-e466-b0e7-abf8-feedf1bf1946-5C7GfCeVMHo@public.gmane.org>
@ 2018-11-26  9:28           ` Christian König
       [not found]             ` <b63c3263-9df8-6c3f-06aa-7b97609d21a6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 12+ messages in thread
From: Christian König @ 2018-11-26  9:28 UTC (permalink / raw)
  To: Zhang, Jerry(Junwei),
	Deucher, Alexander, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW


[-- Attachment #1.1: Type: text/plain, Size: 3276 bytes --]

Am 26.11.18 um 03:38 schrieb Zhang, Jerry(Junwei):
> On 11/24/18 3:32 AM, Deucher, Alexander wrote:
>>
>> Is this required?  Are the harvesting fuses incorrect?  If the blocks 
>> are harvested, we should bail out of the blocks properly during init. 
>>  Also, please make this more explicit if we still need it.  E.g.,
>>
>>
>
> The harvest fuse is indeed disabling UVD and VCE, as it's a mining card.
> Then any command to UVD/VCE causing NULL pointer issue, like amdgpu_test.

In this case we should fix the NULL pointer issue instead. Do you have a 
backtrace for this?

Regards,
Christian.

>
> AFAIW, windows also disable UVD and VCE in initialization.
>
>>        if ((adev->pdev->device == 0x67df) &&
>>               (adev->pdev->revision == 0xf7)) {
>>
>> /* Some polaris12 variants don't support UVD/VCE */
>>
>>       } else  {
>>
>> amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>>
>> amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>>
>>     }
>>
>>
>
> OK, will explicit the process.
>
> Regards,
> Jerry
>>
>> That way if we re-arrange the order later, it will be easier to track.
>>
>>
>> Alex
>>
>> ------------------------------------------------------------------------
>> *From:* amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of 
>> Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
>> *Sent:* Friday, November 23, 2018 3:32:27 AM
>> *To:* amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> *Cc:* Zhang, Jerry
>> *Subject:* [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 
>> variants
>> Some variants don't support UVD and VCE.
>>
>> Signed-off-by: Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
>> ---
>>  drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c 
>> b/drivers/gpu/drm/amd/amdgpu/vi.c
>> index f3a4cf1f013a..3338b013ded4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
>> @@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
>> amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
>>                  amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
>>                  amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
>> +               /* Some polaris12 variants don't support UVD/VCE */
>> +               if ((adev->pdev->device == 0x67df) &&
>> +                     (adev->pdev->revision == 0xf7))
>> +                       break;
>>                  amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>>                  amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>>                  break;
>> -- 
>> 2.17.1
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[-- Attachment #1.2: Type: text/html, Size: 9204 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
       [not found]             ` <b63c3263-9df8-6c3f-06aa-7b97609d21a6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2018-11-27  1:47               ` Zhang, Jerry(Junwei)
       [not found]                 ` <962b81c0-358b-0447-d496-9b8efe817261-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 12+ messages in thread
From: Zhang, Jerry(Junwei) @ 2018-11-27  1:47 UTC (permalink / raw)
  To: christian.koenig-5C7GfCeVMHo, Deucher, Alexander,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW


[-- Attachment #1.1: Type: text/plain, Size: 3870 bytes --]

On 11/26/18 5:28 PM, Christian König wrote:
> Am 26.11.18 um 03:38 schrieb Zhang, Jerry(Junwei):
>> On 11/24/18 3:32 AM, Deucher, Alexander wrote:
>>>
>>> Is this required? Are the harvesting fuses incorrect?  If the blocks 
>>> are harvested, we should bail out of the blocks properly during 
>>> init.  Also, please make this more explicit if we still need it.  E.g.,
>>>
>>>
>>
>> The harvest fuse is indeed disabling UVD and VCE, as it's a mining card.
>> Then any command to UVD/VCE causing NULL pointer issue, like amdgpu_test.
>
> In this case we should fix the NULL pointer issue instead. Do you have 
> a backtrace for this?

Sorry to miss the detail.
The NULL pointer is caused by UVD is not initialized as it's disabled in 
VBIOS for this kind of card.

When cs submit, it will check ring->funcs->parse_cs in amdgpu_cs_ib_fill().
However, uvd_v6_0_early_init() skip the set ring function, as 
CC_HARVEST_FUSES is set UVD/VCE disabled.
Then the access to UVD/VCE ring's funcs will cause NULL pointer issue.

BTW, Windows driver disables UVD/VCE for it as well.

Regards,
Jerry

>
> Regards,
> Christian.
>
>>
>> AFAIW, windows also disable UVD and VCE in initialization.
>>
>>>        if ((adev->pdev->device == 0x67df) &&
>>>               (adev->pdev->revision == 0xf7)) {
>>>
>>> /* Some polaris12 variants don't support UVD/VCE */
>>>
>>>       } else  {
>>>
>>> amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>>>
>>> amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>>>
>>>     }
>>>
>>>
>>
>> OK, will explicit the process.
>>
>> Regards,
>> Jerry
>>>
>>> That way if we re-arrange the order later, it will be easier to track.
>>>
>>>
>>> Alex
>>>
>>> ------------------------------------------------------------------------
>>> *From:* amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of 
>>> Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
>>> *Sent:* Friday, November 23, 2018 3:32:27 AM
>>> *To:* amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>> *Cc:* Zhang, Jerry
>>> *Subject:* [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 
>>> variants
>>> Some variants don't support UVD and VCE.
>>>
>>> Signed-off-by: Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c 
>>> b/drivers/gpu/drm/amd/amdgpu/vi.c
>>> index f3a4cf1f013a..3338b013ded4 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
>>> @@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
>>> amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
>>>                  amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
>>>                  amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
>>> +               /* Some polaris12 variants don't support UVD/VCE */
>>> +               if ((adev->pdev->device == 0x67df) &&
>>> +                     (adev->pdev->revision == 0xf7))
>>> +                       break;
>>>                  amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>>>                  amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>>>                  break;
>>> -- 
>>> 2.17.1
>>>
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>


[-- Attachment #1.2: Type: text/html, Size: 10412 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
       [not found]                 ` <962b81c0-358b-0447-d496-9b8efe817261-5C7GfCeVMHo@public.gmane.org>
@ 2018-11-27  9:56                   ` Christian König
       [not found]                     ` <31393f87-a966-4e90-7cdf-e00676124f73-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 12+ messages in thread
From: Christian König @ 2018-11-27  9:56 UTC (permalink / raw)
  To: Zhang, Jerry(Junwei),
	christian.koenig-5C7GfCeVMHo, Deucher, Alexander,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW


[-- Attachment #1.1: Type: text/plain, Size: 4708 bytes --]

Am 27.11.18 um 02:47 schrieb Zhang, Jerry(Junwei):
> On 11/26/18 5:28 PM, Christian König wrote:
>> Am 26.11.18 um 03:38 schrieb Zhang, Jerry(Junwei):
>>> On 11/24/18 3:32 AM, Deucher, Alexander wrote:
>>>>
>>>> Is this required? Are the harvesting fuses incorrect?  If the 
>>>> blocks are harvested, we should bail out of the blocks properly 
>>>> during init.  Also, please make this more explicit if we still need 
>>>> it.  E.g.,
>>>>
>>>>
>>>
>>> The harvest fuse is indeed disabling UVD and VCE, as it's a mining card.
>>> Then any command to UVD/VCE causing NULL pointer issue, like 
>>> amdgpu_test.
>>
>> In this case we should fix the NULL pointer issue instead. Do you 
>> have a backtrace for this?
>
> Sorry to miss the detail.
> The NULL pointer is caused by UVD is not initialized as it's disabled 
> in VBIOS for this kind of card.

Yeah, but that should be handled correctly.

>
> When cs submit, it will check ring->funcs->parse_cs in 
> amdgpu_cs_ib_fill().
> However, uvd_v6_0_early_init() skip the set ring function, as 
> CC_HARVEST_FUSES is set UVD/VCE disabled.
> Then the access to UVD/VCE ring's funcs will cause NULL pointer issue.
>
> BTW, Windows driver disables UVD/VCE for it as well.

You are approaching this from the wrong side. The fact that UVD/VCE is 
disabled should already be handled correctly.

The problem is rather that in a couple of places (amdgpu_ctx_init for 
example) we assume that we have at least one UVD/VCE ring.

Alex is right that checking the fuses should be sufficient and we rather 
need to fix the handling here instead of adding another workaround.

Regards,
Christian.

>
> Regards,
> Jerry
>
>>
>> Regards,
>> Christian.
>>
>>>
>>> AFAIW, windows also disable UVD and VCE in initialization.
>>>
>>>>        if ((adev->pdev->device == 0x67df) &&
>>>>               (adev->pdev->revision == 0xf7)) {
>>>>
>>>> /* Some polaris12 variants don't support UVD/VCE */
>>>>
>>>>       } else  {
>>>>
>>>> amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>>>>
>>>> amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>>>>
>>>>     }
>>>>
>>>>
>>>
>>> OK, will explicit the process.
>>>
>>> Regards,
>>> Jerry
>>>>
>>>> That way if we re-arrange the order later, it will be easier to track.
>>>>
>>>>
>>>> Alex
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf 
>>>> of Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
>>>> *Sent:* Friday, November 23, 2018 3:32:27 AM
>>>> *To:* amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>>> *Cc:* Zhang, Jerry
>>>> *Subject:* [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 
>>>> variants
>>>> Some variants don't support UVD and VCE.
>>>>
>>>> Signed-off-by: Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
>>>> ---
>>>>  drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
>>>>  1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c 
>>>> b/drivers/gpu/drm/amd/amdgpu/vi.c
>>>> index f3a4cf1f013a..3338b013ded4 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
>>>> @@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
>>>> amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
>>>>                  amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
>>>>                  amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
>>>> +               /* Some polaris12 variants don't support UVD/VCE */
>>>> +               if ((adev->pdev->device == 0x67df) &&
>>>> +                     (adev->pdev->revision == 0xf7))
>>>> +                       break;
>>>>                  amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>>>>                  amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>>>>                  break;
>>>> -- 
>>>> 2.17.1
>>>>
>>>> _______________________________________________
>>>> amd-gfx mailing list
>>>> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>>
>>>
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[-- Attachment #1.2: Type: text/html, Size: 12499 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
       [not found]                     ` <31393f87-a966-4e90-7cdf-e00676124f73-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2018-11-27 16:11                       ` Alex Deucher
       [not found]                         ` <CADnq5_NOaJShmdMvbuiykPXfC7LZneZ8U54feDU4EWYcZSQ5fw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 12+ messages in thread
From: Alex Deucher @ 2018-11-27 16:11 UTC (permalink / raw)
  To: Christian Koenig; +Cc: Junwei Zhang, Deucher, Alexander, amd-gfx list

On Tue, Nov 27, 2018 at 4:56 AM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
>
> Am 27.11.18 um 02:47 schrieb Zhang, Jerry(Junwei):
>
> On 11/26/18 5:28 PM, Christian König wrote:
>
> Am 26.11.18 um 03:38 schrieb Zhang, Jerry(Junwei):
>
> On 11/24/18 3:32 AM, Deucher, Alexander wrote:
>
> Is this required?  Are the harvesting fuses incorrect?  If the blocks are harvested, we should bail out of the blocks properly during init.  Also, please make this more explicit if we still need it.  E.g.,
>
>
>
> The harvest fuse is indeed disabling UVD and VCE, as it's a mining card.
> Then any command to UVD/VCE causing NULL pointer issue, like amdgpu_test.
>
>
> In this case we should fix the NULL pointer issue instead. Do you have a backtrace for this?
>
>
> Sorry to miss the detail.
> The NULL pointer is caused by UVD is not initialized as it's disabled in VBIOS for this kind of card.
>
>
> Yeah, but that should be handled correctly.
>
>
> When cs submit, it will check ring->funcs->parse_cs in amdgpu_cs_ib_fill().
> However, uvd_v6_0_early_init() skip the set ring function, as CC_HARVEST_FUSES is set UVD/VCE disabled.
> Then the access to UVD/VCE ring's funcs will cause NULL pointer issue.
>
> BTW, Windows driver disables UVD/VCE for it as well.
>
>
> You are approaching this from the wrong side. The fact that UVD/VCE is disabled should already be handled correctly.
>
> The problem is rather that in a couple of places (amdgpu_ctx_init for example) we assume that we have at least one UVD/VCE ring.
>
> Alex is right that checking the fuses should be sufficient and we rather need to fix the handling here instead of adding another workaround.

Exactly.  There are already cards out there with no UVD or VCE, so we
need to fix this if it's a problem.  It sounds like userspace is
submitting work to the VCE or UVD rings without checking whether or
not the device supports them in the first place.  We should do a
better job of guarding against that in the kernel.

Alex

>
> Regards,
> Christian.
>
>
> Regards,
> Jerry
>
>
> Regards,
> Christian.
>
>
> AFAIW, windows also disable UVD and VCE in initialization.
>
>        if ((adev->pdev->device == 0x67df) &&
>               (adev->pdev->revision == 0xf7)) {
>
>         /* Some polaris12 variants don't support UVD/VCE */
>
>       } else  {
>
>                  amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>
>                  amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>
>     }
>
>
>
> OK, will explicit the process.
>
> Regards,
> Jerry
>
> That way if we re-arrange the order later, it will be easier to track.
>
>
> Alex
>
> ________________________________
> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> on behalf of Junwei Zhang <Jerry.Zhang@amd.com>
> Sent: Friday, November 23, 2018 3:32:27 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhang, Jerry
> Subject: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
>
> Some variants don't support UVD and VCE.
>
> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index f3a4cf1f013a..3338b013ded4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
>                          amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
>                  amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
>                  amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
> +               /* Some polaris12 variants don't support UVD/VCE */
> +               if ((adev->pdev->device == 0x67df) &&
> +                     (adev->pdev->revision == 0xf7))
> +                       break;
>                  amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>                  amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>                  break;
> --
> 2.17.1
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
       [not found]                         ` <CADnq5_NOaJShmdMvbuiykPXfC7LZneZ8U54feDU4EWYcZSQ5fw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2018-11-28  3:48                           ` Zhang, Jerry
       [not found]                             ` <C7F70BA5-6F05-49FC-87DC-90DE04807BC9-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 12+ messages in thread
From: Zhang, Jerry @ 2018-11-28  3:48 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Zhang, Jerry, Deucher, Alexander, Koenig, Christian, amd-gfx list

在 2018年11月28日,00:11,Alex Deucher <alexdeucher@gmail.com> 写道:
> 
> On Tue, Nov 27, 2018 at 4:56 AM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>> 
>> Am 27.11.18 um 02:47 schrieb Zhang, Jerry(Junwei):
>> 
>> On 11/26/18 5:28 PM, Christian König wrote:
>> 
>> Am 26.11.18 um 03:38 schrieb Zhang, Jerry(Junwei):
>> 
>> On 11/24/18 3:32 AM, Deucher, Alexander wrote:
>> 
>> Is this required?  Are the harvesting fuses incorrect?  If the blocks are harvested, we should bail out of the blocks properly during init.  Also, please make this more explicit if we still need it.  E.g.,
>> 
>> 
>> 
>> The harvest fuse is indeed disabling UVD and VCE, as it's a mining card.
>> Then any command to UVD/VCE causing NULL pointer issue, like amdgpu_test.
>> 
>> 
>> In this case we should fix the NULL pointer issue instead. Do you have a backtrace for this?
>> 
>> 
>> Sorry to miss the detail.
>> The NULL pointer is caused by UVD is not initialized as it's disabled in VBIOS for this kind of card.
>> 
>> 
>> Yeah, but that should be handled correctly.
>> 
>> 
>> When cs submit, it will check ring->funcs->parse_cs in amdgpu_cs_ib_fill().
>> However, uvd_v6_0_early_init() skip the set ring function, as CC_HARVEST_FUSES is set UVD/VCE disabled.
>> Then the access to UVD/VCE ring's funcs will cause NULL pointer issue.
>> 
>> BTW, Windows driver disables UVD/VCE for it as well.
>> 
>> 
>> You are approaching this from the wrong side. The fact that UVD/VCE is disabled should already be handled correctly.
>> 
>> The problem is rather that in a couple of places (amdgpu_ctx_init for example) we assume that we have at least one UVD/VCE ring.
>> 
>> Alex is right that checking the fuses should be sufficient and we rather need to fix the handling here instead of adding another workaround.
> 
> Exactly.  There are already cards out there with no UVD or VCE, so we
> need to fix this if it's a problem.  It sounds like userspace is
> submitting work to the VCE or UVD rings without checking whether or
> not the device supports them in the first place.  We should do a
> better job of guarding against that in the kernel.

Thanks your all.
Got that meaning now.

we may also print some message that UVD/VCE is not initialized, since it looks initialized successfully.
```
[   15.730219] [drm] add ip block number 7 <uvd_v6_0>
```
I could check it after the vacation(back next week).

BTW, is that handled by the patch series of [PATCH 1/6] drm/amdgpu: add VCN JPEG support amdgpu_ctx_num_entities?
Try to apply the patches, seems amdgpu_test hang at Userptr Test, verified on latest staging build
Please confirm that.

[ 4388.759743] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 4388.759782] IP: amddrm_sched_entity_flush+0x2d/0x1d0 [amd_sched]
[ 4388.759807] PGD 0 P4D 0
[ 4388.759820] Oops: 0000 [#1] SMP PTI
[ 4388.759834] Modules linked in: amdgpu(OE) amdchash(OE) amdttm(OE) amd_sched(OE) amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt nls_utf8 cifs ccm rpcsec_gss_krb5 nfsv4 nfs fscache b
infmt_misc nls_iso8859_1 snd_hda_codec_realtek snd_hda_codec_generic intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_intel irqbypass crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hda_co
re snd_hwdep ghash_clmulni_intel snd_seq_midi snd_seq_midi_event pcbc snd_pcm snd_rawmidi snd_seq snd_seq_device snd_timer aesni_intel aes_x86_64 crypto_simd eeepc_wmi glue_helper snd cryptd asus_wmi intel_cstate soundcore shpchp intel_ra
pl_perf mei_me wmi_bmof intel_wmi_thunderbolt sparse_keymap serio_raw mei acpi_pad mac_hid sch_fq_codel
[ 4388.760141]  nfsd auth_rpcgss nfs_acl parport_pc lockd ppdev grace lp sunrpc parport ip_tables x_tables autofs4 mxm_wmi e1000e psmouse ptp pps_core ahci libahci wmi video
[ 4388.760212] CPU: 7 PID: 915 Comm: amdgpu_test Tainted: G           OE    4.15.0-39-generic #42-Ubuntu
[ 4388.760250] Hardware name: System manufacturer System Product Name/Z170-A, BIOS 1302 11/09/2015
[ 4388.760287] RIP: 0010:amddrm_sched_entity_flush+0x2d/0x1d0 [amd_sched]
[ 4388.760314] RSP: 0018:ffffa37b8166bd38 EFLAGS: 00010246
[ 4388.760337] RAX: 0000000000000000 RBX: ffff88776740e5f8 RCX: 0000000000000000
[ 4388.760366] RDX: 0000000000000000 RSI: 00000000000000fa RDI: ffff88776740e5f8
[ 4388.760396] RBP: ffffa37b8166bd88 R08: ffff8877765dab10 R09: 0000000000000000
[ 4388.760425] R10: 0000000000000000 R11: 0000000000000064 R12: 00000000000000fa
[ 4388.760455] R13: ffff8877606fdf18 R14: ffff8877606fdef8 R15: 00000000000000fa
[ 4388.760484] FS:  00007f05b21a1580(0000) GS:ffff8877765c0000(0000) knlGS:0000000000000000
[ 4388.760518] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4388.760542] CR2: 0000000000000008 CR3: 000000003020a005 CR4: 00000000003606e0
[ 4388.760572] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4388.760601] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4388.760630] Call Trace:
[ 4388.760644]  ? wait_woken+0x80/0x80
[ 4388.760701]  amdgpu_ctx_mgr_entity_flush+0x7b/0xc0 [amdgpu]
[ 4388.760747]  amdgpu_flush+0x23/0x30 [amdgpu]
[ 4388.760767]  filp_close+0x2f/0x80
[ 4388.760782]  put_files_struct+0x78/0xf0
[ 4388.760967]  exit_files+0x49/0x50
[ 4388.760976]  do_exit+0x2ca/0xb40
[ 4388.760985]  ? __do_page_fault+0x270/0x4d0
[ 4388.760994]  do_group_exit+0x43/0xb0
[ 4388.761003]  SyS_exit_group+0x14/0x20
[ 4388.761013]  do_syscall_64+0x73/0x130
[ 4388.761023]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 4388.761034] RIP: 0033:0x7f05b143fe06
[ 4388.761043] RSP: 002b:00007ffd0fde5fa8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[ 4388.761059] RAX: ffffffffffffffda RBX: 00007f05b1742740 RCX: 00007f05b143fe06
[ 4388.761074] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
[ 4388.761088] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80
[ 4388.761103] R10: 00007f05b135a140 R11: 0000000000000246 R12: 00007f05b1742740
[ 4388.761117] R13: 0000000000000001 R14: 00007f05b174b628 R15: 0000000000000000
[ 4388.761132] Code: 44 00 00 55 48 89 e5 41 56 41 55 41 54 53 48 89 fb 49 89 f4 48 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 45 d8 31 c0 48 8b 47 10 <4c> 8b 68 08 65 48 8b 04 25 00 5c 01 00 f6 40 24 04 0f 84 1b 01 
[ 4388.761188] RIP: amddrm_sched_entity_flush+0x2d/0x1d0 [amd_sched] RSP: ffffa37b8166bd38
[ 4388.761204] CR2: 0000000000000008
[ 4388.761212] ---[ end trace 7f1dd38e3cb86992 ]---
[ 4388.761222] Fixing recursive fault but reboot is needed!


Regards,
Jerry


> 
> Alex
> 
>> 
>> Regards,
>> Christian.
>> 
>> 
>> Regards,
>> Jerry
>> 
>> 
>> Regards,
>> Christian.
>> 
>> 
>> AFAIW, windows also disable UVD and VCE in initialization.
>> 
>>       if ((adev->pdev->device == 0x67df) &&
>>              (adev->pdev->revision == 0xf7)) {
>> 
>>        /* Some polaris12 variants don't support UVD/VCE */
>> 
>>      } else  {
>> 
>>                 amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>> 
>>                 amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>> 
>>    }
>> 
>> 
>> 
>> OK, will explicit the process.
>> 
>> Regards,
>> Jerry
>> 
>> That way if we re-arrange the order later, it will be easier to track.
>> 
>> 
>> Alex
>> 
>> ________________________________
>> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> on behalf of Junwei Zhang <Jerry.Zhang@amd.com>
>> Sent: Friday, November 23, 2018 3:32:27 AM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Zhang, Jerry
>> Subject: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
>> 
>> Some variants don't support UVD and VCE.
>> 
>> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
>> index f3a4cf1f013a..3338b013ded4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
>> @@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
>>                         amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
>>                 amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
>>                 amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
>> +               /* Some polaris12 variants don't support UVD/VCE */
>> +               if ((adev->pdev->device == 0x67df) &&
>> +                     (adev->pdev->revision == 0xf7))
>> +                       break;
>>                 amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>>                 amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>>                 break;
>> --
>> 2.17.1
>> 
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>> 
>> 
>> 
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>> 
>> 
>> 
>> 
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>> 
>> 
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
       [not found]                             ` <C7F70BA5-6F05-49FC-87DC-90DE04807BC9-5C7GfCeVMHo@public.gmane.org>
@ 2018-11-28 15:00                               ` Deucher, Alexander
  0 siblings, 0 replies; 12+ messages in thread
From: Deucher, Alexander @ 2018-11-28 15:00 UTC (permalink / raw)
  To: Zhang, Jerry, Alex Deucher; +Cc: Koenig, Christian, amd-gfx list


[-- Attachment #1.1: Type: text/plain, Size: 9974 bytes --]

Yes, my intention was that that patch series may fix the issue you are seeing, but it wasn't exactly clear where the bug was.


Alex

________________________________
From: Zhang, Jerry
Sent: Tuesday, November 27, 2018 10:48:15 PM
To: Alex Deucher
Cc: Koenig, Christian; Zhang, Jerry; Deucher, Alexander; amd-gfx list
Subject: Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants

在 2018年11月28日,00:11,Alex Deucher <alexdeucher@gmail.com> 写道:
>
> On Tue, Nov 27, 2018 at 4:56 AM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>>
>> Am 27.11.18 um 02:47 schrieb Zhang, Jerry(Junwei):
>>
>> On 11/26/18 5:28 PM, Christian König wrote:
>>
>> Am 26.11.18 um 03:38 schrieb Zhang, Jerry(Junwei):
>>
>> On 11/24/18 3:32 AM, Deucher, Alexander wrote:
>>
>> Is this required?  Are the harvesting fuses incorrect?  If the blocks are harvested, we should bail out of the blocks properly during init.  Also, please make this more explicit if we still need it.  E.g.,
>>
>>
>>
>> The harvest fuse is indeed disabling UVD and VCE, as it's a mining card.
>> Then any command to UVD/VCE causing NULL pointer issue, like amdgpu_test.
>>
>>
>> In this case we should fix the NULL pointer issue instead. Do you have a backtrace for this?
>>
>>
>> Sorry to miss the detail.
>> The NULL pointer is caused by UVD is not initialized as it's disabled in VBIOS for this kind of card.
>>
>>
>> Yeah, but that should be handled correctly.
>>
>>
>> When cs submit, it will check ring->funcs->parse_cs in amdgpu_cs_ib_fill().
>> However, uvd_v6_0_early_init() skip the set ring function, as CC_HARVEST_FUSES is set UVD/VCE disabled.
>> Then the access to UVD/VCE ring's funcs will cause NULL pointer issue.
>>
>> BTW, Windows driver disables UVD/VCE for it as well.
>>
>>
>> You are approaching this from the wrong side. The fact that UVD/VCE is disabled should already be handled correctly.
>>
>> The problem is rather that in a couple of places (amdgpu_ctx_init for example) we assume that we have at least one UVD/VCE ring.
>>
>> Alex is right that checking the fuses should be sufficient and we rather need to fix the handling here instead of adding another workaround.
>
> Exactly.  There are already cards out there with no UVD or VCE, so we
> need to fix this if it's a problem.  It sounds like userspace is
> submitting work to the VCE or UVD rings without checking whether or
> not the device supports them in the first place.  We should do a
> better job of guarding against that in the kernel.

Thanks your all.
Got that meaning now.

we may also print some message that UVD/VCE is not initialized, since it looks initialized successfully.
```
[   15.730219] [drm] add ip block number 7 <uvd_v6_0>
```
I could check it after the vacation(back next week).

BTW, is that handled by the patch series of [PATCH 1/6] drm/amdgpu: add VCN JPEG support amdgpu_ctx_num_entities?
Try to apply the patches, seems amdgpu_test hang at Userptr Test, verified on latest staging build
Please confirm that.

[ 4388.759743] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 4388.759782] IP: amddrm_sched_entity_flush+0x2d/0x1d0 [amd_sched]
[ 4388.759807] PGD 0 P4D 0
[ 4388.759820] Oops: 0000 [#1] SMP PTI
[ 4388.759834] Modules linked in: amdgpu(OE) amdchash(OE) amdttm(OE) amd_sched(OE) amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt nls_utf8 cifs ccm rpcsec_gss_krb5 nfsv4 nfs fscache b
infmt_misc nls_iso8859_1 snd_hda_codec_realtek snd_hda_codec_generic intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_intel irqbypass crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hda_co
re snd_hwdep ghash_clmulni_intel snd_seq_midi snd_seq_midi_event pcbc snd_pcm snd_rawmidi snd_seq snd_seq_device snd_timer aesni_intel aes_x86_64 crypto_simd eeepc_wmi glue_helper snd cryptd asus_wmi intel_cstate soundcore shpchp intel_ra
pl_perf mei_me wmi_bmof intel_wmi_thunderbolt sparse_keymap serio_raw mei acpi_pad mac_hid sch_fq_codel
[ 4388.760141]  nfsd auth_rpcgss nfs_acl parport_pc lockd ppdev grace lp sunrpc parport ip_tables x_tables autofs4 mxm_wmi e1000e psmouse ptp pps_core ahci libahci wmi video
[ 4388.760212] CPU: 7 PID: 915 Comm: amdgpu_test Tainted: G           OE    4.15.0-39-generic #42-Ubuntu
[ 4388.760250] Hardware name: System manufacturer System Product Name/Z170-A, BIOS 1302 11/09/2015
[ 4388.760287] RIP: 0010:amddrm_sched_entity_flush+0x2d/0x1d0 [amd_sched]
[ 4388.760314] RSP: 0018:ffffa37b8166bd38 EFLAGS: 00010246
[ 4388.760337] RAX: 0000000000000000 RBX: ffff88776740e5f8 RCX: 0000000000000000
[ 4388.760366] RDX: 0000000000000000 RSI: 00000000000000fa RDI: ffff88776740e5f8
[ 4388.760396] RBP: ffffa37b8166bd88 R08: ffff8877765dab10 R09: 0000000000000000
[ 4388.760425] R10: 0000000000000000 R11: 0000000000000064 R12: 00000000000000fa
[ 4388.760455] R13: ffff8877606fdf18 R14: ffff8877606fdef8 R15: 00000000000000fa
[ 4388.760484] FS:  00007f05b21a1580(0000) GS:ffff8877765c0000(0000) knlGS:0000000000000000
[ 4388.760518] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4388.760542] CR2: 0000000000000008 CR3: 000000003020a005 CR4: 00000000003606e0
[ 4388.760572] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4388.760601] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4388.760630] Call Trace:
[ 4388.760644]  ? wait_woken+0x80/0x80
[ 4388.760701]  amdgpu_ctx_mgr_entity_flush+0x7b/0xc0 [amdgpu]
[ 4388.760747]  amdgpu_flush+0x23/0x30 [amdgpu]
[ 4388.760767]  filp_close+0x2f/0x80
[ 4388.760782]  put_files_struct+0x78/0xf0
[ 4388.760967]  exit_files+0x49/0x50
[ 4388.760976]  do_exit+0x2ca/0xb40
[ 4388.760985]  ? __do_page_fault+0x270/0x4d0
[ 4388.760994]  do_group_exit+0x43/0xb0
[ 4388.761003]  SyS_exit_group+0x14/0x20
[ 4388.761013]  do_syscall_64+0x73/0x130
[ 4388.761023]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 4388.761034] RIP: 0033:0x7f05b143fe06
[ 4388.761043] RSP: 002b:00007ffd0fde5fa8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[ 4388.761059] RAX: ffffffffffffffda RBX: 00007f05b1742740 RCX: 00007f05b143fe06
[ 4388.761074] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
[ 4388.761088] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80
[ 4388.761103] R10: 00007f05b135a140 R11: 0000000000000246 R12: 00007f05b1742740
[ 4388.761117] R13: 0000000000000001 R14: 00007f05b174b628 R15: 0000000000000000
[ 4388.761132] Code: 44 00 00 55 48 89 e5 41 56 41 55 41 54 53 48 89 fb 49 89 f4 48 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 45 d8 31 c0 48 8b 47 10 <4c> 8b 68 08 65 48 8b 04 25 00 5c 01 00 f6 40 24 04 0f 84 1b 01
[ 4388.761188] RIP: amddrm_sched_entity_flush+0x2d/0x1d0 [amd_sched] RSP: ffffa37b8166bd38
[ 4388.761204] CR2: 0000000000000008
[ 4388.761212] ---[ end trace 7f1dd38e3cb86992 ]---
[ 4388.761222] Fixing recursive fault but reboot is needed!


Regards,
Jerry


>
> Alex
>
>>
>> Regards,
>> Christian.
>>
>>
>> Regards,
>> Jerry
>>
>>
>> Regards,
>> Christian.
>>
>>
>> AFAIW, windows also disable UVD and VCE in initialization.
>>
>>       if ((adev->pdev->device == 0x67df) &&
>>              (adev->pdev->revision == 0xf7)) {
>>
>>        /* Some polaris12 variants don't support UVD/VCE */
>>
>>      } else  {
>>
>>                 amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>>
>>                 amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>>
>>    }
>>
>>
>>
>> OK, will explicit the process.
>>
>> Regards,
>> Jerry
>>
>> That way if we re-arrange the order later, it will be easier to track.
>>
>>
>> Alex
>>
>> ________________________________
>> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> on behalf of Junwei Zhang <Jerry.Zhang@amd.com>
>> Sent: Friday, November 23, 2018 3:32:27 AM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Zhang, Jerry
>> Subject: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
>>
>> Some variants don't support UVD and VCE.
>>
>> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/vi.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
>> index f3a4cf1f013a..3338b013ded4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
>> @@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
>>                         amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
>>                 amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
>>                 amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
>> +               /* Some polaris12 variants don't support UVD/VCE */
>> +               if ((adev->pdev->device == 0x67df) &&
>> +                     (adev->pdev->revision == 0xf7))
>> +                       break;
>>                 amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>>                 amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>>                 break;
>> --
>> 2.17.1
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>>
>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[-- Attachment #1.2: Type: text/html, Size: 14498 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
       [not found] ` <20181123080144.24427-1-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
@ 2018-11-23  8:32   ` Zhang, Jerry(Junwei)
  0 siblings, 0 replies; 12+ messages in thread
From: Zhang, Jerry(Junwei) @ 2018-11-23  8:32 UTC (permalink / raw)
  To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

please ignore this patch, there is typo in code.

On 11/23/18 4:01 PM, Junwei Zhang wrote:
> Some variants don't support UVD and VCE.
>
> Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/vi.c | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index f3a4cf1f013a..46a92eca831b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1660,6 +1660,11 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
>   			amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
>   		amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
>   		amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
> +		/* Some polaris12 variants don't support UVD/VCE */
> +		if (((adev->pdev->device == 0x67df) &&
> +		     ((adev->pdev->revision == 0xe1) ||
> +		      (adev->pdev->revision == 0xf7))))
> +			break;
>   		amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
>   		amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
>   		break;

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants
@ 2018-11-23  8:01 Junwei Zhang
       [not found] ` <20181123080144.24427-1-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 12+ messages in thread
From: Junwei Zhang @ 2018-11-23  8:01 UTC (permalink / raw)
  To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW; +Cc: Junwei Zhang

Some variants don't support UVD and VCE.

Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index f3a4cf1f013a..46a92eca831b 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1660,6 +1660,11 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
 			amdgpu_device_ip_block_add(adev, &dce_v11_2_ip_block);
 		amdgpu_device_ip_block_add(adev, &gfx_v8_0_ip_block);
 		amdgpu_device_ip_block_add(adev, &sdma_v3_1_ip_block);
+		/* Some polaris12 variants don't support UVD/VCE */
+		if (((adev->pdev->device == 0x67df) &&
+		     ((adev->pdev->revision == 0xe1) ||
+		      (adev->pdev->revision == 0xf7))))
+			break;
 		amdgpu_device_ip_block_add(adev, &uvd_v6_3_ip_block);
 		amdgpu_device_ip_block_add(adev, &vce_v3_4_ip_block);
 		break;
-- 
2.17.1

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

^ permalink raw reply related	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2018-11-28 15:00 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-23  8:32 [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants Junwei Zhang
     [not found] ` <20181123083227.25555-1-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
2018-11-23  9:19   ` Cui, Flora
2018-11-23 19:32   ` Deucher, Alexander
     [not found]     ` <BN6PR12MB18091B4409C1DC5CD17F903CF7D40-/b2+HYfkarSEx6ez0IUAagdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2018-11-26  2:38       ` Zhang, Jerry(Junwei)
     [not found]         ` <b8a49f59-e466-b0e7-abf8-feedf1bf1946-5C7GfCeVMHo@public.gmane.org>
2018-11-26  9:28           ` Christian König
     [not found]             ` <b63c3263-9df8-6c3f-06aa-7b97609d21a6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-11-27  1:47               ` Zhang, Jerry(Junwei)
     [not found]                 ` <962b81c0-358b-0447-d496-9b8efe817261-5C7GfCeVMHo@public.gmane.org>
2018-11-27  9:56                   ` Christian König
     [not found]                     ` <31393f87-a966-4e90-7cdf-e00676124f73-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-11-27 16:11                       ` Alex Deucher
     [not found]                         ` <CADnq5_NOaJShmdMvbuiykPXfC7LZneZ8U54feDU4EWYcZSQ5fw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-11-28  3:48                           ` Zhang, Jerry
     [not found]                             ` <C7F70BA5-6F05-49FC-87DC-90DE04807BC9-5C7GfCeVMHo@public.gmane.org>
2018-11-28 15:00                               ` Deucher, Alexander
  -- strict thread matches above, loose matches on Subject: below --
2018-11-23  8:01 Junwei Zhang
     [not found] ` <20181123080144.24427-1-Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>
2018-11-23  8:32   ` Zhang, Jerry(Junwei)

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.