答复: 答复: 答复: [PATCH] drm/amdgpu:fix amdgpu_sa_bo_new error

[Liu, Monk]

that's because some customer modified QEMU and trap each VF's memory access, which cost too much time if using CPU access FB,


emmm, I guess we have no better choice by far,  do as you suggested,


to kill risk the negative effect that we may have no console if ib test failed, I suggest we don't block driver proceeding after ib test failure detected , doable ?

________________________________
发件人: Christian König <deathsimple at vodafone.de>
发送时间: 2017年2月8日 23:59:10
收件人: Liu, Monk; Michel Dänzer
抄送: amd-gfx at lists.freedesktop.org
主题: Re: 答复: 答复: [PATCH] drm/amdgpu:fix amdgpu_sa_bo_new error

Am 08.02.2017 um 16:53 schrieb Liu, Monk:

agreed, why not just use cpu to clear it ? is it because performance ?

Pixel Ding removed the CPU clear because "There's a failure caused by this is that handshaking gets timeout of SRIOV virtual function."

I can only assume that this is really adding to much delay at bootup.


________________________________
发件人: Michel Dänzer <michel at daenzer.net><mailto:michel at daenzer.net>
发送时间: 2017年2月8日 23:52:02
收件人: Christian König; Liu, Monk
抄送: amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org>
主题: Re: 答复: [PATCH] drm/amdgpu:fix amdgpu_sa_bo_new error

On 09/02/17 12:30 AM, Christian König wrote:
> The IB test make the decision if the hardware is working or not.
>
> So they should be the first commands (except for the ring tests) we send
> to the hardware.
>
> When we allocate the fb before the test we send the clear command to the
> hardware without knowing if the hardware really works or not.
>
> Not a big issue, but I think the order makes more sense that way.

I just wonder if it's worth all the trouble, just to clear the fbcon
buffer[0], if the result is that the console output is delayed, possibly
indefinitely.

Actually that change is quite beneficial because the IB tests where usually revealing any problem.

Not 100% sure, but when we initialize the fb later that might actually allow us to better track such problems down.

Going to check that,
Christian.


[0] We don't have any other hardware acceleration for fbcon, so its BO
is only accessed by the CPU and display hardware after this, and has to
be pinned in the CPU visible area of VRAM at all times anyway.


--
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

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