[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.

[Michel Dänzer]

On 16/08/16 04:00 PM, Deng, Emily wrote:
>> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf Of
>> Michel D?nzer
>> Sent: Tuesday, August 16, 2016 2:43 PM
>> On 16/08/16 03:28 PM, Deng, Emily wrote:
>>>> From: Michel Dänzer [mailto:michel at daenzer.net]
>>>> Sent: Tuesday, August 16, 2016 12:01 PM On 16/08/16 12:49 PM, Deng,
>>>> Emily wrote:
>>>>> Hi Michel, Thanks, I still couldn't see the issue that use a
>>>>> variable to calculate the vblank count when vsync timer interrupt
>>>>> occurs. I just think it only emulates the hardware behavior. And the
>>>>> code change will only in virtual display files which won't touch drm
>>>>> layer. I incline to not modify the code in drm layer or amdgpu other
>>>>> codes, because it may lead to other issues .
>>>>
>>>> I see it basically the other way around: We are currently pretending
>>>> to the DRM core code that we have a reliable hardware vblank counter
>>>> and timing even in the virtual DCE case, when we really don't. We
>>>> should stop pretending and instead communicate the lack of these
>>>> hardware facilities in the virtual DCE case as intended, otherwise we'll
>> probably run into issues sooner or later.
>>>>
>>> [[EmilyD]] Hi Michel, yes, you are right, we are pretending a hardware
>>> vblank counter in virtual DCE case to drm layer. But can you specific some
>> cases that we must communicate with drm layer that we don't have the vblank
>> counter.
>>
>> I described all the necessary steps (that I know of; there may be more) in
>> https://lists.freedesktop.org/archives/amd-gfx/2016-August/001342.html .
>>
> [[EmilyD]] Hi Michel, I means can you detail the reasons or cases that we should communicate with drm layer 
> when don't have the vblank counter instead of pretending a hardware vblank counter in virtual DCE case.

The DRM core code expects the get_vblank_counter hook to use a reliable
hardware counter. If that is not the case, it should always return 0.

Similarly, drm_calc_vbltimestamp_from_scanoutpos expects the
get_scanout_position hook to return accurate scanout position values
based on reliable hardware registers.

If we pretend to return accurate values from these when we actually
can't, the DRM core code may provide incorrect vblank counter /
timestamp values to userspace, or worse.

Those are just off the top of my head, there may be more along the same
lines.


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