From: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
To: Shaik Ameer Basha <shaik.ameer@samsung.com>
Cc: linux-media@vger.kernel.org, s.nawrocki@samsung.com,
kgene.kim@samsung.com, shaik.samsung@gmail.com,
Hans Verkuil <hverkuil@xs4all.nl>,
Kamil Debski <k.debski@samsung.com>,
Sakari Ailus <sakari.ailus@iki.fi>
Subject: Re: [PATCH] [media] exynos-gsc: propagate timestamps from src to dst buffers
Date: Mon, 19 Nov 2012 23:06:34 +0100 [thread overview]
Message-ID: <50AAAD6A.80709@gmail.com> (raw)
In-Reply-To: <1352270424-14683-1-git-send-email-shaik.ameer@samsung.com>
Hi Shaik,
On 11/07/2012 07:40 AM, Shaik Ameer Basha wrote:
> Make gsc-m2m propagate the timestamp field from source to destination
> buffers
We probably need some means for letting know the mem-to-mem drivers and
applications whether timestamps are copied from OUTPUT to CAPTURE or not.
Timestamps at only OUTPUT interface are normally used to control buffer
processing time [1].
"struct timeval timestamp
For input streams this is the system time (as returned by the
gettimeofday()
function) when the first data byte was captured. For output streams the
data
will not be displayed before this time, secondary to the nominal frame rate
determined by the current video standard in enqueued order. Applications
can
for example zero this field to display frames as soon as possible. The
driver
stores the time at which the first data byte was actually sent out in the
timestamp field. This permits applications to monitor the drift between the
video and system clock."
In some use cases it might be useful to know exact frame processing time,
where driver would be filling OUTPUT and CAPTURE value with exact monotonic
clock values corresponding to a frame processing start and end time.
[1] http://linuxtv.org/downloads/v4l-dvb-apis/buffer.html#v4l2-buffer
For the time being I'm OK with this patch, just one comment below...
> Signed-off-by: John Sheu<sheu@google.com>
> Signed-off-by: Shaik Ameer Basha<shaik.ameer@samsung.com>
> ---
> drivers/media/platform/exynos-gsc/gsc-m2m.c | 19 ++++++++++++-------
> 1 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c b/drivers/media/platform/exynos-gsc/gsc-m2m.c
> index 047f0f0..1139276 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
> @@ -99,22 +99,27 @@ static void gsc_m2m_job_abort(void *priv)
> gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
> }
>
> -static int gsc_fill_addr(struct gsc_ctx *ctx)
> +static int gsc_get_bufs(struct gsc_ctx *ctx)
> {
> struct gsc_frame *s_frame, *d_frame;
> - struct vb2_buffer *vb = NULL;
> + struct vb2_buffer *src_vb, *dst_vb;
> int ret;
>
> s_frame =&ctx->s_frame;
> d_frame =&ctx->d_frame;
>
> - vb = v4l2_m2m_next_src_buf(ctx->m2m_ctx);
> - ret = gsc_prepare_addr(ctx, vb, s_frame,&s_frame->addr);
> + src_vb = v4l2_m2m_next_src_buf(ctx->m2m_ctx);
> + ret = gsc_prepare_addr(ctx, src_vb, s_frame,&s_frame->addr);
Might be better to just return any error code
if (ret)
return ret;
> + dst_vb = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
> + ret |= gsc_prepare_addr(ctx, dst_vb, d_frame,&d_frame->addr);
...rather than obfuscating the return value here.
> if (ret)
> return ret;
>
> - vb = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
> - return gsc_prepare_addr(ctx, vb, d_frame,&d_frame->addr);
> + memcpy(&dst_vb->v4l2_buf.timestamp,&src_vb->v4l2_buf.timestamp,
> + sizeof(dst_vb->v4l2_buf.timestamp));
Is there any advantage of memcpy over simple assignment
dst_vb->v4l2_buf.timestamp = src_vb->v4l2_buf.timestamp;
?
> + return 0;
> }
>
> static void gsc_m2m_device_run(void *priv)
> @@ -148,7 +153,7 @@ static void gsc_m2m_device_run(void *priv)
> goto put_device;
> }
>
> - ret = gsc_fill_addr(ctx);
> + ret = gsc_get_bufs(ctx);
> if (ret) {
> pr_err("Wrong address");
> goto put_device;
--
Thanks,
Sylwester
next prev parent reply other threads:[~2012-11-19 22:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-07 6:40 [PATCH] [media] exynos-gsc: propagate timestamps from src to dst buffers Shaik Ameer Basha
2012-11-19 22:06 ` Sylwester Nawrocki [this message]
2012-11-21 19:39 ` Sakari Ailus
2012-11-22 9:32 ` Kamil Debski
2012-11-22 21:25 ` 'Sakari Ailus'
2012-11-22 21:44 ` Sylwester Nawrocki
2012-11-25 12:09 ` Sakari Ailus
2012-11-27 13:09 ` Laurent Pinchart
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=50AAAD6A.80709@gmail.com \
--to=sylvester.nawrocki@gmail.com \
--cc=hverkuil@xs4all.nl \
--cc=k.debski@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=linux-media@vger.kernel.org \
--cc=s.nawrocki@samsung.com \
--cc=sakari.ailus@iki.fi \
--cc=shaik.ameer@samsung.com \
--cc=shaik.samsung@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.