From: Imre Deak <imre.deak@intel.com>
To: Rob Clark <rob.clark@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFC 4/4] drm: add support for raw monotonic vblank timestamps
Date: Sat, 06 Oct 2012 03:49:16 +0300 [thread overview]
Message-ID: <1349484556.23130.15.camel@ideak-mobl> (raw)
In-Reply-To: <CAF6AEGtN9WmL5QKct=3NbrEnz0KeX7ozuZ=cn+a-YX9v0xY04g@mail.gmail.com>
On Fri, 2012-10-05 at 18:09 -0600, Rob Clark wrote:
> On Fri, Oct 5, 2012 at 5:41 PM, Imre Deak <imre.deak@intel.com> wrote:
> > On Fri, 2012-10-05 at 16:18 -0600, Rob Clark wrote:
> >> On Fri, Oct 5, 2012 at 7:37 AM, Imre Deak <imre.deak@intel.com> wrote:
> >> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >> > index ab1ef15..056e810 100644
> >> > --- a/drivers/gpu/drm/i915/intel_display.c
> >> > +++ b/drivers/gpu/drm/i915/intel_display.c
> >> > @@ -6247,7 +6247,6 @@ static void do_intel_finish_page_flip(struct drm_device *dev,
> >> > struct intel_unpin_work *work;
> >> > struct drm_i915_gem_object *obj;
> >> > struct drm_pending_vblank_event *e;
> >> > - struct timeval tvbl;
> >> > unsigned long flags;
> >> >
> >> > /* Ignore early vblank irqs */
> >> > @@ -6264,12 +6263,13 @@ static void do_intel_finish_page_flip(struct drm_device *dev,
> >> > intel_crtc->unpin_work = NULL;
> >> >
> >> > if (work->event) {
> >> > - e = work->event;
> >> > - e->event.sequence = drm_vblank_count_and_time(dev, intel_crtc->pipe, &tvbl);
> >> > -
> >> > - e->event.tv_sec = tvbl.tv_sec;
> >> > - e->event.tv_usec = tvbl.tv_usec;
> >> > + struct drm_vblank_time tvbl;
> >> > + u32 seq;
> >> >
> >> > + e = work->event;
> >> > + seq = drm_vblank_count_and_time(dev, intel_crtc->pipe, &tvbl);
> >> > + drm_set_event_seq_and_time(&e->event, e->timestamp_raw, seq,
> >> > + &tvbl);
> >> > list_add_tail(&e->base.link,
> >> > &e->base.file_priv->event_list);
> >> > wake_up_interruptible(&e->base.file_priv->event_wait);
> >>
> >>
> >> btw, I wonder if we could just have a helper like:
> >>
> >> int drm_send_page_flip_event(struct drm_device *dev, int crtc,
> >> struct drm_pending_vblank_event *event);
> >>
> >> Since most drivers have pretty much the same code for sending vblank
> >> event after a page flip..
> >>
> >> I guess not strictly related to monotonic timestamps, but it has been
> >> a cleanup that I've been meaning to do for a while.. and I guess if
> >> this was done first it wouldn't mean touching each driver (as much) to
> >> add support for monotonic timestamps.
> >
> > Good idea, we should do this.
> >
> > But if we want to reduce the diff from my changes then the proto should
> > rather be:
> >
> > int drm_send_page_flip_event(struct drm_device *dev, int crtc,
> > struct drm_pending_vblank_event *event,
> > int seq, struct timeval *now);
>
> do we need 'seq' and 'now'? I was sort of thinking that could all be
> internal to the send_page_flip_event() fxn.. ie. like:
>
> ---------
> void drm_send_page_flip_event(struct drm_device *dev, int pipe,
> struct drm_crtc *crtc, struct drm_pending_vblank_event *event)
> {
> struct timeval tnow, tvbl;
>
> do_gettimeofday(&tnow);
>
> event->event.sequence = drm_vblank_count_and_time(dev, pipe, &tvbl);
Ah, ok, you are right. I originally thought of using this helper in
drm_handle_vblank_events too, but now I realized it's not quite the same
sequence there.
>
> /* Called before vblank count and timestamps have
> * been updated for the vblank interval of flip
> * completion? Need to increment vblank count and
> * add one videorefresh duration to returned timestamp
> * to account for this. We assume this happened if we
> * get called over 0.9 frame durations after the last
> * timestamped vblank.
> *
> * This calculation can not be used with vrefresh rates
> * below 5Hz (10Hz to be on the safe side) without
> * promoting to 64 integers.
> */
> if (10 * (timeval_to_ns(&tnow) - timeval_to_ns(&tvbl)) >
> 9 * crtc->framedur_ns) {
> event->event.sequence++;
> tvbl = ns_to_timeval(timeval_to_ns(&tvbl) +
> crtc->framedur_ns);
> }
This has been recently removed by danvet's "drm/i915: don't frob the
vblank ts in finish_page_flip", though not yet committed, so we can do
away with it here too.
> event->event.tv_sec = tvbl.tv_sec;
> event->event.tv_usec = tvbl.tv_usec;
>
> list_add_tail(&event->base.link,
> &event->base.file_priv->event_list);
> wake_up_interruptible(&event->base.file_priv->event_wait);
> }
> ---------
>
> well, this would be the pre-monotonic timestamp version.. and it is a
> bit weird to have to pass in both crtc ptr and pipe #.. I don't see
> anything obvious in drm core that links pipe # and crtc ptr, although
> userspace seems to make this assumption about order of crtc's. But I
> think that if() statement is only in i915 driver.. I assume because
> you don't know if this will get called before or after
> drm_handle_vblank()? I guess that shouldn't hurt for other drivers.
>
> then each driver would just have something like:
>
> ---------
> if (work->event)
> drm_send_page_flip_event(dev, intel_crtc->pipe, crtc, work->event);
> ---------
>
>
> > with struct timeval changing to struct drm_vblank_time with my changes.
> >
> > I can do this if you agree - unless you have something ready.
>
> I've locally split out this into a helper fxn in omapdrm, but haven't
> got around to pushing it to core and updating other drivers. If you
> want I can send a patch, but I guess it is easier to just include
> something like this in your patchset. I'm ok either way.
I think the easiest is if you post your updated patch since it can be
anyway applied independently. I'll then rebase my changes on top of
that.
Thanks,
Imre
next prev parent reply other threads:[~2012-10-06 0:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-05 13:36 [RFC 0/4] drm: add raw monotonic timestamp support Imre Deak
2012-10-05 13:36 ` [RFC 1/4] time: export getnstime_raw_and_real for DRM Imre Deak
2012-10-05 16:14 ` Kristian Høgsberg
2012-10-09 10:25 ` Imre Deak
2012-10-05 13:37 ` [RFC 2/4] drm: make memset/calloc for _vblank_time more robust Imre Deak
2012-10-05 13:37 ` [RFC 3/4] drm: use raw time in drm_calc_vbltimestamp_from_scanoutpos Imre Deak
2012-10-05 13:37 ` [RFC 4/4] drm: add support for raw monotonic vblank timestamps Imre Deak
2012-10-05 13:55 ` Michel Dänzer
2012-10-05 13:59 ` Imre Deak
2012-10-05 14:14 ` Michel Dänzer
2012-10-05 14:21 ` Imre Deak
2012-10-05 22:18 ` Rob Clark
2012-10-05 23:41 ` Imre Deak
2012-10-06 0:09 ` Rob Clark
2012-10-06 0:49 ` Imre Deak [this message]
2012-10-07 20:33 ` Daniel Vetter
2012-10-05 23:07 ` [RFC 0/4] drm: add raw monotonic timestamp support Eric Anholt
2012-10-08 11:22 ` Imre Deak
2012-10-11 10:29 ` Laurent Pinchart
2012-10-11 11:21 ` Imre Deak
2012-10-11 10:32 ` Laurent Pinchart
2012-10-11 11:22 ` Imre Deak
2012-10-23 18:53 ` [PATCH 0/2] drm: add " Imre Deak
2012-10-23 18:53 ` [PATCH 1/2] drm: use monotonic time in drm_calc_vbltimestamp_from_scanoutpos Imre Deak
2012-10-24 23:05 ` Mario Kleiner
2012-10-25 10:28 ` Imre Deak
2012-10-25 19:45 ` Mario Kleiner
2012-10-23 18:53 ` [PATCH 2/2] drm: add support for monotonic vblank timestamps Imre Deak
2012-10-24 8:08 ` Michel Dänzer
2012-10-24 11:40 ` Imre Deak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1349484556.23130.15.camel@ideak-mobl \
--to=imre.deak@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rob.clark@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).