linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: Alexandre Courbot <acourbot@chromium.org>
Cc: Stanimir Varbanov <stanimir.varbanov@linaro.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	linux-arm-msm@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] media: venus: fix reported size of 0-length buffers
Date: Thu, 15 Nov 2018 11:49:53 -0500	[thread overview]
Message-ID: <463ac42b795933a54daa8d2bbba3ff1ac2b733db.camel@ndufresne.ca> (raw)
In-Reply-To: <CAPBb6MWJ1Qu9YoRRusOGiC7dioMkgvU=1dCF6XZ4xDUxp7ri9A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

Le mercredi 14 novembre 2018 à 13:12 +0900, Alexandre Courbot a écrit :
> On Wed, Nov 14, 2018 at 3:54 AM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
> > 
> > 
> > Le mar. 13 nov. 2018 04 h 30, Alexandre Courbot <acourbot@chromium.org> a écrit :
> > > The last buffer is often signaled by an empty buffer with the
> > > V4L2_BUF_FLAG_LAST flag set. Such buffers were returned with the
> > > bytesused field set to the full size of the OPB, which leads
> > > user-space to believe that the buffer actually contains useful data. Fix
> > > this by passing the number of bytes reported used by the firmware.
> > 
> > That means the driver does not know on time which one is last. Why not just returned EPIPE to userspace on DQBUF and ovoid this useless roundtrip ?
> 
> Sorry, I don't understand what you mean. EPIPE is supposed to be
> returned after a buffer with V4L2_BUF_FLAG_LAST is made available for
> dequeue. This patch amends the code that prepares this LAST-flagged
> buffer. How could we avoid a roundtrip in this case?

Maybe it has changed, but when this was introduced, we found that some
firmware (Exynos MFC) could not know which one is last. Instead, it
gets an event saying there will be no more buffers.

Sending buffers with payload size to 0 just for the sake of setting the
V4L2_BUF_FLAG_LAST was considered a waste. Specially that after that,
every polls should return EPIPE. So in the end, we decided the it
should just unblock the userspace and return EPIPE.

If you look at the related GStreamer code, it completely ignores the
LAST flag. With fake buffer of size 0, userspace will endup dequeuing
and throwing away. This is not useful to the process of terminating the
decoding. To me, this LAST flag is not useful in this context.

Nicolas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2018-11-16  2:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-13  9:30 [PATCH] media: venus: fix reported size of 0-length buffers Alexandre Courbot
     [not found] ` <CAKQmDh-91tHP1VxLisW1A3GR9G7du3F-Y2XrrgoFU=gvhGoP6w@mail.gmail.com>
2018-11-14  4:12   ` Alexandre Courbot
2018-11-15 16:49     ` Nicolas Dufresne [this message]
2018-11-15 16:51       ` Nicolas Dufresne
2018-11-16  4:08       ` Tomasz Figa
2018-11-22  8:31       ` Alexandre Courbot
2018-11-22 23:53         ` Nicolas Dufresne
2018-11-26  8:23           ` Alexandre Courbot
2018-11-26  8:54         ` Stanimir Varbanov
2018-11-26  9:45 ` Stanimir Varbanov

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=463ac42b795933a54daa8d2bbba3ff1ac2b733db.camel@ndufresne.ca \
    --to=nicolas@ndufresne.ca \
    --cc=acourbot@chromium.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=stanimir.varbanov@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).