From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
LMML <linux-media@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] media: omap3isp: ispvideo: drop driver specific isp_video_fh
Date: Tue, 24 Feb 2015 11:07:53 +0200 [thread overview]
Message-ID: <1975486.DZ2Ir2MLZP@avalon> (raw)
In-Reply-To: <CA+V-a8urdZhD97m4mQu_aYLWW9Kf0PSx=ddhbvteb-HRz2hEEA@mail.gmail.com>
Hi Prabhakar,
On Tuesday 24 February 2015 08:04:40 Lad, Prabhakar wrote:
> On Tue, Feb 24, 2015 at 12:35 AM, Laurent Pinchart wrote:
> > On Monday 23 February 2015 20:19:32 Lad Prabhakar wrote:
> >> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
> >>
> >> this patch drops driver specific isp_video_fh, as this
> >> can be handled by core.
> >
> > I'm afraid it's not that simple.
> >
> > The omap3isp driver stores video queues per file handle for a reason. This
> > was design to permit creating a high-resolution still image capture queue
> > and prepare buffers ahead of time, to avoid the large delay due to cache
> > management as prepare time when taking the snapshot.
>
> Ah I see the reason.
>
> > Now this use case has been partially solved by VIDIOC_CREATE_BUFS, but
> > we're still missing a VIDIOC_DESTROY_BUFS to make it work completely.
> > That needs to be solved first.
>
> I haven't used the VIDIOC_CREATE_BUFS ioctl so far in any of the apps
> so cant comment much on this.
> But isn't that obvious we need VIDIOC_DESTROY_BUFS or is there any backdoor
> to destroy them that I am missing ?
You can destroy buffers allocated with CREATE_BUFS using REQBUFS(0), but you
can't destroy them individually without a new ioctl.
> >> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> >> ---
> >>
> >> drivers/media/platform/omap3isp/ispvideo.c | 128 +++++++++--------------
> >> drivers/media/platform/omap3isp/ispvideo.h | 13 +--
> >> 2 files changed, 49 http://vger.kernel.org/majordomo-info.html
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2015-02-24 9:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 20:19 [PATCH 0/3] omap3isp trivial enhancements Lad Prabhakar
2015-02-23 20:19 ` [PATCH 1/3] media: omap3isp: ispvideo: drop setting of vb2 buffer state to VB2_BUF_STATE_ACTIVE Lad Prabhakar
2015-02-24 0:12 ` Laurent Pinchart
2015-02-23 20:19 ` [PATCH 2/3] media: omap3isp: ispvideo: drop driver specific isp_video_fh Lad Prabhakar
2015-02-24 0:35 ` Laurent Pinchart
2015-02-24 8:04 ` Lad, Prabhakar
2015-02-24 9:07 ` Laurent Pinchart [this message]
2015-02-23 20:19 ` [PATCH 3/3] media: omap3isp: ispvideo: use vb2_fop_mmap/poll Lad Prabhakar
2015-02-24 0:23 ` Laurent Pinchart
2015-02-24 7:54 ` Lad, Prabhakar
2015-03-08 20:19 ` 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=1975486.DZ2Ir2MLZP@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=prabhakar.csengg@gmail.com \
--cc=sakari.ailus@linux.intel.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.