[PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants

[Christian König]

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 at lists.freedesktop.org> on behalf 
>>>> of Junwei Zhang <Jerry.Zhang at amd.com>
>>>> *Sent:* Friday, November 23, 2018 3:32:27 AM
>>>> *To:* amd-gfx at 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 at 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 at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>>
>>>
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20181127/2ddef936/attachment-0001.html>