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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 16, 2016 at 03:43:07PM +0900, Michel Dänzer wrote:
> 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.

Yes please don't lie to the vblank core. In the future we might depend
more on this, and that might lead to surprises.

> > [[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 .

Yeah I missed the accurate timestamp part, since on i915 on gen2 we can
still do that part. Your todo list looks accurate from what I can tell.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux