improved swap/MSC-wait scheduling in DPMS-off state

[Ilija Hadzic]

The following set of patches is a follow-up to a discussion that took place
on this list back in December [1]. It was about how the MSC-wait and
swap-scheduling functions should behave when CRTC is not running because
the display is shut off (in DPMS-off state). We left off with a set of
patches (now in Git) that fixed the acute problem that prompted the
discussion [2]. As a quick reminder, the problem was that when display
went into DPMS-off state, swap function was returning immediately making
the client run at uncontrolled pace, unnecessarily dissipating extra
power on the CPU and GPU (and probably defeating the power savings
achieved by shutting the display off).

The solution that was accepted was a simple one (block the client for a
constant time period) and, at the end of the discussion, I promised
to follow up with a more sophisticated solution: the one that would
fully emulate a running CRTC and make the client run at the same pace
that it was running while the display was on [3].

I was finally able to find some time to work on this (apologies for
long delay). The patch-set that follows should achieve the stated
objective. I managed to keep the modification confined to the DDX.
No new functionality is needed from X-server or any other library
except one #define in libdrm which should go into libdrm anyway
(it was sent to dri-devel list but has not been merged yet [4]).

The emulation of a running CRTC works like this: When CRTC is about
to be turned off, the last vblank time, sequence number, and frequency
are recorded. The vblank counter no longer progresses after this point.
If MSC, MSC-wait or swap are requested while the CRTC is off, the
DDX looks at the current time and the previously recorded information
about vblanks and extrapolates how many vblanks would have passed
by that time. If necessary, it looks at target_msc sent by the client
and calculates at what time it would happen if the CRTC were running.
At this point the DDX has all the information to schedule the wait
or swap using Xorg's timers facility and make up the MSC by adding
the extrapolated value to the last actual vblank value.

When the CRTC goes back into the running state the DDX reverts back
to normal use of vblanks, but the MSC number must now be offset
by any number of vblanks that would fit in the time period spent
in DPMS-off state (i.e., interpolated vblanks). As the CRTC goes in
and out of DPMS on/off state the number of interpolated vblanks
(offset added to vblank counter to produce MSC) accumulates. As the
result, the MSC progresses continuously through DPMS states and the
its frequency matches the vblank frequency determined by the
last mode used on the CRTC.

The end result is that regardless in which state the display is, the
application sees the events (time and sequence numbers) that progress
as if the CRTC is running and the events happen at right time points
on the grid determined by the vlbanks (real or interpolated).

thanks,

Ilija

[1] http://lists.x.org/archives/xorg-driver-ati/2012-December/024141.html
[2] http://lists.x.org/archives/xorg-driver-ati/2012-December/024194.html
[3] http://lists.x.org/archives/xorg-driver-ati/2012-December/024198.html
[4] http://lists.freedesktop.org/archives/dri-devel/2012-November/030852.html