From: Rob Clark <rob.clark@linaro.org>
To: Imre Deak <imre.deak@intel.com>
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: Fri, 5 Oct 2012 18:09:21 -0600 [thread overview]
Message-ID: <CAF6AEGtN9WmL5QKct=3NbrEnz0KeX7ozuZ=cn+a-YX9v0xY04g@mail.gmail.com> (raw)
In-Reply-To: <1349480477.21982.12.camel@ideak-mobl>
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);
/* 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);
}
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.
BR,
-R
> --Imre
>
>>
>> BR,
>> -R
>>
>> > diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
>> > index 7ddef8f..55c014a 100644
>> > --- a/drivers/gpu/drm/radeon/radeon_display.c
>> > +++ b/drivers/gpu/drm/radeon/radeon_display.c
>> > @@ -272,7 +272,6 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev, int crtc_id)
>> > struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
>> > struct radeon_unpin_work *work;
>> > struct drm_pending_vblank_event *e;
>> > - struct timeval now;
>> > unsigned long flags;
>> > u32 update_pending;
>> > int vpos, hpos;
>> > @@ -329,10 +328,13 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev, int crtc_id)
>> >
>> > /* wakeup userspace */
>> > if (work->event) {
>> > + struct drm_vblank_time now;
>> > + u32 seq;
>> > +
>> > e = work->event;
>> > - e->event.sequence = drm_vblank_count_and_time(rdev->ddev, crtc_id, &now);
>> > - e->event.tv_sec = now.tv_sec;
>> > - e->event.tv_usec = now.tv_usec;
>> > + seq = drm_vblank_count_and_time(rdev->ddev, crtc_id, &now);
>> > + drm_set_event_seq_and_time(&e->event, e->timestamp_raw,
>> > + seq, &now);
>> > list_add_tail(&e->base.link, &e->base.file_priv->event_list);
>> > wake_up_interruptible(&e->base.file_priv->event_wait);
>> > }
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2012-10-06 0:09 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 [this message]
2012-10-06 0:49 ` Imre Deak
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='CAF6AEGtN9WmL5QKct=3NbrEnz0KeX7ozuZ=cn+a-YX9v0xY04g@mail.gmail.com' \
--to=rob.clark@linaro.org \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.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).