WB _init should clear this buffer in very early stage, so it should output 0 if 
for BARE-METAL or no preemption occurred 

-----Original Message-----
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: 2017年10月13日 17:10
To: Ding, Pixel <pixel.d...@amd.com>; amd-gfx@lists.freedesktop.org
Cc: Li, Bingley <bingley...@amd.com>
Subject: Re: [PATCH 3/4] drm/amdgpu: report preemption fence via 
amdgpu_fence_info

Hi Pixel,

> My understanding is that CP will write seqno back to preempted fence offset 
> when preemption occurred.
That is correct.

But my question is why you want to print a different value here:
> +             seq_printf(m, "Last preempted      0x%08x\n",
> +                        le32_to_cpu(*(ring->fence_drv.cpu_addr + 2)));

That code prints two dw after the address where the CPU writes the seqno. Where 
is the code which setups the CP to do this?

As far as I can see that line should always print just zero (or some random 
number if the memory is actually not initialized to anything).

Regards,
Christian.

Am 13.10.2017 um 11:03 schrieb Ding, Pixel:
> My understanding is that CP will write seqno back to preempted fence offset 
> when preemption occurred. Then if there is a value here we can generally know 
> packet with which fence is preempted. Should driver handle any other thing 
> for this?
>                                       
>                               
>                       
>               
>       
>
>
> —
> Sincerely Yours,
> Pixel
>
>
>
>
>
>
>
> On 13/10/2017, 4:51 PM, "Koenig, Christian" <christian.koe...@amd.com> wrote:
>
>>> 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.
>> The question is where is this code for Tonga and Vega? I can't find a 
>> reference to fence_offs in the GFX8 nor GFX9 code we have in 
>> amd-staging-drm-next.
>>
>> And if it doesn't depend on the fence_offs in the ring printing it 
>> like this is just pure speculation.
>>
>> Regards,
>> Christian.
>>
>> Am 13.10.2017 um 10:41 schrieb 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.leichtzumer...@gmail.com> wrote:
>>>
>>>> Am 13.10.2017 um 10:26 schrieb Pixel Ding:
>>>>> From: pding <pixel.d...@amd.com>
>>>>>
>>>>> Only report fence for GFX ring. This can help checking MCBP feature.
>>>>>
>>>>> Signed-off-by: pding <pixel.d...@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;
>>>>>     }


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reply via email to