Re: [PATCH V2] drm/vkms: Add vblank events simulated by hrtimers

[Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>]

Hi and thanks for all the feedback, I will work on the suggestions you sent,
but I have some doubts:

On 07/05, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-07-05 09:20:13)
> > On Thu, Jul 05, 2018 at 12:48:43AM -0300, Rodrigo Siqueira wrote:
> > > +     ktime_t current_timestamp;
> > > +
> > > +     hrtimer_init(&out->vblank_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> > 
> > Can't we use absolute timer mode here? That avoids all the timestampt
> > computations.
> 
> Where's your absolute timestamp being computed?

I did not understand the question. hrtimer_forward_now calculates the
absolute timestamp from the relative value provided, this is what I am
using. In any case, it would be easy to switch to absolute mode, but
the code would not be smaller (or larger).

> What's being done is recomputing what hrtimer already knows given a
> relative interval. output->expires should be equivalent to
> hrtimer->expires, and a lot of this code evaporates.

Indeed, output->expires can be removed; as for the rest of the code, that
depends on the answer to question 2 below.

I have two questions:

1. The timestamp that is returned to userspace is (A) the timestamp when the
interrupt was actually handled, allowing applications to detect when there
is some irregularities in the interrupt handling timing, or (B) the timestamp
when the current interrupt was *scheduled* to happen, allowing applications
to detect overruns but not variations in the interrupt handling timing?

2. If I use hrtimer with a period of 1s and return HRTIMER_RESTART, will I
be called back (A) 1s after the previous iteration was *scheduled to start*
(i.e., I will actually be called back at regular intervals, so that after
1,000 iterations approximately 1,000s have elapsed) or (B) 1s after the
previous iteration *ended* (i.e., I will be called back at intervals of
1s + the average processing time of the function, so that after 1,000
iterations significantly more than 1,000s have elapsed)?

The code I wrote assumes the answer to both questions is (B). If the
answer to the second question is A, the code can indeed be made much
simpler; if the answer to the first question is A, I have not been able
to keep timing within the expected strict limits of the IGT test in a VM
(maybe on physical hardware things would go better).

Thanks
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel