All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arun Kumar K <arun.kk@samsung.com>
To: linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org
Cc: k.debski@samsung.com, posciak@chromium.org,
	avnd.kiran@samsung.com, arunkk.samsung@gmail.com
Subject: [PATCH 01/10] [media] s5p-mfc: Copy timestamps only when a frame is produced.
Date: Mon, 19 May 2014 18:02:57 +0530	[thread overview]
Message-ID: <1400502786-4826-2-git-send-email-arun.kk@samsung.com> (raw)
In-Reply-To: <1400502786-4826-1-git-send-email-arun.kk@samsung.com>

From: Pawel Osciak <posciak@chromium.org>

Timestamps for destination buffers are assigned by copying them from
corresponding source buffers when the decode operation results in a frame
being outputted to a destination buffer. But the decision when to do this, i.e.
whether the decode operation on current source buffer produced a destination
frame, is wrongly based on "display status". Display status reflects the status
of the destination buffer, not source.

This used to work for firmwares version <= 6, because in addition to the above,
we'd check the decoded frame type register, which was set to "skipped" if
a destination frame was not produced, exiting early from
s5p_mfc_handle_frame_new().
Firmware >=7 does not set the frame type register for frames that were not
decoded anymore though, which results in us wrongly overwriting timestamps of
previously decoded buffers (firmware reports the same destination buffer address
as previously decoded one if a frame wasn't decoded during current operation).

To do it properly, we should be basing our decision to copy the timestamp on the
status of the source buffer, i.e. "decode status". The decode status register
values are confusing, because in its case "display" means "a frame has been
outputted to a destination buffer". We should copy if "decode and display"
is returned in it. This also works on <= v6 firmware, which behaves in the same
way with regards to decode status register.

Signed-off-by: Pawel Osciak <posciak@chromium.org>
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 89356ae..6ef6bd1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -309,12 +309,15 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	unsigned int dst_frame_status;
+	unsigned int dec_frame_status;
 	struct s5p_mfc_buf *src_buf;
 	unsigned long flags;
 	unsigned int res_change;
 
 	dst_frame_status = s5p_mfc_hw_call(dev->mfc_ops, get_dspl_status, dev)
 				& S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK;
+	dec_frame_status = s5p_mfc_hw_call(dev->mfc_ops, get_dec_status, dev)
+				& S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK;
 	res_change = (s5p_mfc_hw_call(dev->mfc_ops, get_dspl_status, dev)
 				& S5P_FIMV_DEC_STATUS_RESOLUTION_MASK)
 				>> S5P_FIMV_DEC_STATUS_RESOLUTION_SHIFT;
@@ -347,8 +350,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
 		}
 	}
 
-	if (dst_frame_status == S5P_FIMV_DEC_STATUS_DECODING_DISPLAY ||
-		dst_frame_status == S5P_FIMV_DEC_STATUS_DECODING_ONLY)
+	if (dec_frame_status == S5P_FIMV_DEC_STATUS_DECODING_DISPLAY)
 		s5p_mfc_handle_frame_copy_time(ctx);
 
 	/* A frame has been decoded and is in the buffer  */
-- 
1.7.9.5


  reply	other threads:[~2014-05-19 12:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-19 12:32 [PATCH 00/10] Re-send MFC patches Arun Kumar K
2014-05-19 12:32 ` Arun Kumar K [this message]
2014-05-19 12:32 ` [PATCH 02/10] [media] s5p-mfc: Fixes for decode REQBUFS Arun Kumar K
2014-05-19 12:32 ` [PATCH 03/10] [media] s5p-mfc: Extract open/close MFC instance commands Arun Kumar K
2014-05-19 12:33 ` [PATCH 04/10] [media] s5p-mfc: Don't allocate codec buffers on STREAMON Arun Kumar K
2014-07-25 16:03   ` Nicolas Dufresne
2014-05-19 12:33 ` [PATCH 05/10] [media] s5p-mfc: Update scratch buffer size for VP8 encoder Arun Kumar K
2014-05-19 12:33 ` [PATCH 06/10] [media] s5p-mfc: Don't try to resubmit VP8 bitstream buffer for decode Arun Kumar K
2014-05-19 12:33 ` [PATCH 07/10] [media] s5p-mfc: Update scratch buffer size for MPEG4 Arun Kumar K
2014-05-19 12:33 ` [PATCH 08/10] [media] s5p-mfc: Move INIT_BUFFER_OPTIONS from v7 to v6 Arun Kumar K
2014-05-19 12:33 ` [PATCH 09/10] [media] s5p-mfc: Add variants to access mfc registers Arun Kumar K
2014-05-19 12:33 ` [PATCH 10/10] [media] s5p-mfc: Rename IS_MFCV7 macro Arun Kumar K

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=1400502786-4826-2-git-send-email-arun.kk@samsung.com \
    --to=arun.kk@samsung.com \
    --cc=arunkk.samsung@gmail.com \
    --cc=avnd.kiran@samsung.com \
    --cc=k.debski@samsung.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=posciak@chromium.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 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.