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 <>
发送时间: 2017年2月8日 23:59:10
收件人: Liu, Monk; Michel Dänzer
主题: 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 <><>
发送时间: 2017年2月8日 23:52:02
收件人: Christian König; Liu, Monk
主题: 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

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,

[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               |     
Libre software enthusiast             |             Mesa and X developer

amd-gfx mailing list

Reply via email to