[PATCH 3/4] drm/amdgpu: report preemption fence via amdgpu_fence_info

[Ding, Pixel]

Thanks Christian,

I’m not sure if I get your point, but yes the preemption fence offset could be changed.

Is it OK to limit this information only for SRIOV VF on Tonga and Vega whose format is known? It can help use to identify if MCBP is working correctly or not.


— 
Sincerely Yours,
Pixel







On 13/10/2017, 4:34 PM, "Christian König" <ckoenig.leichtzumerken at gmail.com> wrote:

>Am 13.10.2017 um 10:26 schrieb Pixel Ding:
>> From: pding <Pixel.Ding at amd.com>
>>
>> Only report fence for GFX ring. This can help checking MCBP feature.
>>
>> Signed-off-by: pding <Pixel.Ding at amd.com>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>> index 09d5a5c..2044758 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>> @@ -645,6 +645,13 @@ static int amdgpu_debugfs_fence_info(struct seq_file *m, void *data)
>>   			   atomic_read(&ring->fence_drv.last_seq));
>>   		seq_printf(m, "Last emitted        0x%08x\n",
>>   			   ring->fence_drv.sync_seq);
>> +
>> +		if (ring->funcs->type != AMDGPU_RING_TYPE_GFX)
>> +			break;
>
>That should probably be "continue" instead of break, or otherwise you 
>don't print the other fences any more.
>
>> +
>> +		seq_printf(m, "Last preempted      0x%08x\n",
>> +			   le32_to_cpu(*(ring->fence_drv.cpu_addr + 2)));
>
>Is the code to put the preemption fence there already upstream?
>
>If yes do we really do this like that for all supported generations?
>
>Regards,
>Christian.
>
>> +
>>   	}
>>   	return 0;
>>   }
>
>