On Tue, Nov 27, 2018 at 4:56 AM Christian König
<[email protected]> 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 <[email protected]> on behalf of Junwei
> Zhang <[email protected]>
> Sent: Friday, November 23, 2018 3:32:27 AM
> To: [email protected]
> 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 <[email protected]>
> ---
> 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
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>
> _______________________________________________
> amd-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>
>
> _______________________________________________
> amd-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
> _______________________________________________
> amd-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
